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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This document defines the Stage 2 architecture and specification for the CS Fallback and for SMS over SGs for EPS or 
CS Fallback and SMS over S102. The scope of this document includes the architecture enhancements for functionality 
to enable fallback from E-UTRAN access to UTRAN/GERAN CS domain access and to CDMA Ix RTT CS domain 
access, and functionality to reuse of voice and other CS-domain services (e.g. CS UDI video / LCS / USSD) by reuse of 
the CS domain. The functionality specified to support SMS over SGs does not trigger any CS Fallback to 
UTRAN/GERAN. The functionality specified to support SMS over SI 02 does not trigger any CS Fallback to CDMA 
IxRTT CS domain. 

In addition this specification includes an SMS in MME architecture option for SMS services only. This functionality 
does not trigger any CS Fallback and does not require SGs. 

The architecture enhancements to support CS fallback to CDMA Ix RTT CS domain access for UEs with single and 
dual receiver configurations are specified in Annex B. 

In this Release of the specification no mechanisms are specified to support CS Fallback to both UTRAN/GERAN and 
CDMA IxRTT in the same PLMN. So, even when a UE has the capability to support both CS Fallback to 
UTRAN/GERAN CS domain and CS Fallback to CDMA IxRTT CS domain in a given PLMN, the PLMN implements 
only one of the two. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] apply. A term defined in the 
present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

IxCS: The 3GPP2 legacy circuit Switched signalling system as defined in 3GPP2 X.S0042-0 [22]. 

CSMT flag: A flag in LA update request message used in CS fallback for MT call to avoid missing paging in roaming 
retry. 

CSMO flag: A flag in CM Service Request and LA Update request message used in CS fallback for MO calls. 

Service User: See TS 22.153 [36]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] apply. An abbreviation defined in 
the present document takes precedence over the definition of the same abbreviation, if any, in TR 2 1 .905 [ 1 ] . 

IxCS IWS Circuit Switched fallback Interworking solution Function for 3GPP2 IxCS. 

CSMT Circuit Switched fallback Mobile Terminated call. 

CSMO Circuit Switched fallback Mobile Originated call. 

eMLPP enhanced Multi Level Precedence and Pre emption 

ICS IMS CentraHsed Services 

MNRF Mobile Station Not Reachable Flag 

MNRF-MME Mobile Not Reachable Flag in MME for SMS 

MPS Multimedia Priority Service 

MTRF Mobile Terminating Roaming Forwarding 

MWD Message Waiting Data 

NAM Network Access Mode 

NEAF Non-EPS Alert Flag. 

SRVCC Single Radio Voice Call Continuity 



4 Overall Description 

4.1 General Considerations 

The CS fallback in EPS enables the provisioning of voice and other CS-domain services (e.g. CS UDl video/ LCS/ 
USSD) by reuse of CS infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, connected 
to E-UTRAN may use GERAN or UTRAN to connect to the CS-domain. This function is only available in case 
E-UTRAN coverage is overlapped by either GERAN coverage or UTRAN coverage. 

CS Fallback and IMS-based services shall be able to co-exist in the same operator"s network. 
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The ICS architecture as defined in TS 23.292 [25] shall be able to co-exist with utilising CS Fallback as the CS domain 
in the same operator's network. 

This specification also specifies the architecture required for SMS over SGs. The MO SMS and MT SMS are signalled 
over SGs and do not cause any CS Fallback to GERAN/UTRAN RATs, and consequently does not require any 
overlapped GERAN/UTRAN coverage. 

Additionally this specification specifies the SMS in MME architecture option as described in Annex C. 

The support of SMS over SGs is mandatory for UE and MME and MSC supporting CS fallback, whereas UE and MME 
and MSC supporting SMS over SGs are not required to support CS fallback. 

NOTE: An MME supporting only SMS over SGs (i.e. not supporting CS fallback) will either reply with "SMS- 
only" or reject an IMSI attach. 

The support of CS fallback (and to a lesser extent SMS over SGs) can impose some operational constraints on Tracking 
Area boundary planning and the use of the "tracking area list concept" (see TS 23.401 [2]). 



4.2 



Reference Architecture 



The CS fallback and SMS over SGs in EPS function is realized by using the SGs interface mechanism between the 
MSC Server and the MME. 

The SGs interface functionality is based on the mechanisms specified for the Gs interface, TS 23.060 [3]. 



UE 



LTE-Uu 




UTRAN 



GERAN 



E-UTRAN 



-lu-ps 



SGSN 




Figure 4.2-1 : EPS architecture for CS fallbacit and SIVIS over SGs 

NOTE 1: The MGW is not shown in the figure 4.2-1 since neither CS fallback in EPS nor SMS over SGs has any 
impacts on the U-plane handling. 

NOTE 2: SGSN and S3 have additional functionary related to ISR and CS fallback/SMS over SGs. If ISR is not 
used, this functionality is not required. 



4.2.1 

SGs: 



S3: 



Reference points 



It is the reference point between the MME and MSC server. The SGs reference point is used for the 
mobility management and paging procedures between EPS and CS domain, and is based on the Gs 
interface procedures. The SGs reference point is also used for the delivery of both mobile originating and 
mobile terminating SMS. Additional procedures for alignment with the Gs reference point are not 
precluded. 

It is defined in TS 23.401 [2] with the additional functionality to support ISR for CS fallback/SMS over 
SGs as defined in this specification. 
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4.3 Functional entities 

4.3.1 UE 

The CS fallback capable UE supports access to E-UTRAN/EPC as well as access to the CS domain over GERAN 
and/or UTRAN. 

The SMS over SGs capable UE supports access to E-UTRAN/EPC and may support access to the CS domain over 
GERAN and/or UTRAN. 

The support of SMS over SGs is mandatory for a UE that supports CS fallback, whereas a UE that supports SMS over 
SGs is not required to support CS fallback. 

These UEs support the following additional functions: 

Combined procedures specified in this document for EPS/IMSI attach, update and detach. 

CS fallback and/or SMS over SGs procedures specified in this document for using CS domain services. 

From the UE's perspective there is no difference whether the MME provides SMS via SGs or by "SMS in MME". 

A UE using CS fallback and/or SMS over SGs supports ISR according to TS 23.401 [2]. In particular a UE deactivates 
ISR at reception of LAU accept or at reception of combined RAU/LAU accept response with no ISR indication. 

The coexistence with IMS services for voice/SMS is defined in clause 4.5. 

There are no other CS fallback/SMS over SGs ISR-specifics for the UE compared to ISR description in TS 23.401 [2], 
i.e. if ISR is active the UE can change between all registered areas and RATs without performing update signalling. The 
UE listens for paging on the RAT it is currently camped on. 

If the UE is service user with subscription to CS domain priority service, the UE's USIM belongs to one of Access Class 
that indicates the priority is needed and the UE shall sets the RRC establishment cause to "HighPriority Access" as 
specified in TS 36.331 [33]. 

4.3.2 IVIIVIE 

The CS fallback and/or SMS over SGs enabled MME supports the following additional functions: 

- Multiple PLMNs selection for the CS domain. 

RAT selection for the CS domain. 

Deriving a VLR number and LAI from the TAI of the current cell and based on the selected PLMN or the 
selected RAT for CS domain, or using a default VLR number and LAI. 

Deliver the registered PLMN ID for CS domain (included in the LAI) to the eNodeB. 

Includes the PLMN ID for the CS domain (included in the LAI provided to the UE) in the equivalent PLMNs list 
if it is different compared to the PLMN ID provided as part of the GUTI. 

For CS fallback, generating a TAI list such that the UE has a low chance of "falling back" to a cell in a LA 
different to the derived LAI (e.g. the TAI list boundary should not cross the LA boundary). 

NOTE: Alignment of the TAI list boundary with a LA boundary can prevent the MME from making effective use 
of the "tracking area list" concept. To compensate for this, appropriate cell reselection hysteresis may 
need to be used within the E-UTRAN. 

- Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE. 

In order for the Serving MSC/VLR to always be up to date with the correct last used LTE PLMN, issuing a 
LOCATION-UPDATE-REQUEST over SGs when the selected LTE PLMN changes: the serving LTE PLMN is 
derived from the TAI included in that message. 

- Initiating IMSI or EPS detach. 
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Initiating paging procedure specified in this document towards eNodeB when MSC pages the UE for CS 
services. 

Supporting SMS procedures defined in this document. 

Rejecting CS Fallback call request (e.g. due to O&M reasons) 

Dependent on configuration, indicating to the MSC that the MO CS service is due to CSFB by sending SGsAP- 
SER VICE-REQUEST as specified in TS 29.1 18 [44]. 

Dependent on configuration, indicating to the SGSN that the UE whose context is retrieved from the MME has 
been subjected to CSFB or that the PS HO procedure is due to CSFB by adding an indication in Forward 
Relocaiton Request as specified in TS 29.274 [45]. 

If the network supports the CSFB procedures during ongoing IMS voice call with SRVCC capability (i.e. 
clauses 8.3 and 8.4) and UE has SRVCC and EMM combined capability and CSFB is selected by the network 
(i.e. not SMS only), then: 

- Selecting a MSC/VLR which is both SRVCC and CSFB capable during combined Attach/TAU procedure. 

- If CSFB triggers SRVCC during ongoing IMS voice call, a PS to CS HO request is sent to the MSCA'LR 
that is registered during the combined Attach/TAU procedure, for which the MME selects an SRVCC and 
CSFB capable MSC/VLR. 

An MME that supports "SMS in MME" shall support additional functions specified in Annex C, clause C.4.2. 

An MME that supports CS Fallback uses the LAI and the TMSI based NRI as provided by the UE or the LAI and a 
hash value from the IMSI to determine the VLR number as defined in TS 23.236 [23] when multiple MSC/VLRs serve 
the same LAI. The NRI distribution or IMSI Hash table shall have a consistent configuration in all MMEs in the pool. 
The same NRI value/hash value/function is used by SGSN to determine the VLR number. An MME that supports SMS 
over SGs may use the same procedure as for CS Fallback. In some networks, the MME may be configured to select the 
MSC/VLR for UEs that send low access priority indication with a different load balance to that used for MSC/VLR 
selection for other UEs. In this case the MME maintains a separate hash/value function for UEs that send low access 
priority indication. 

If the network supports CSFB priority call handling, the MME supports the following additional functions: 

For paging message received on the SGs interface with priority indication, the MME provides preferential 
treatment to this message and also the subsequent CS fallback procedure compared to other normal procedures. 
If UE needs to be paged, the MME sets priority indication on the paging request to eNodeB. The MME also sets 
priority indication, i.e. "CSFB High Priority", in SlAP message to the eNodeB, so that eNodeB can initiate the 
CSFB procedure with priority, as specified in TS 36.413 [35]. 

For a CSFB request from a service user, the MME determines that the CSFB request needs priority handling 
based on the MPS CS Priority stored in UE's EPS subscription. The MME provides preferential treatment to this 
request and also sets priority indication, i.e. "CSFB High Priority", in SlAP message to eNodeB to initiate CSFB 
procedure with priority, as specified in TS 36.413 [35]. 

4.3.3 MSC 

The CS fallback and/or SMS over SGs enabled MSC supports the following additional functions: 

- Maintaining SGs association towards MME for EPS/IMSI attached UE. 

Supporting SMS procedures defined in this document. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC 
indicates to GERAN/UTRAN that the RR connection was established as a result of CS fallback. 

- During the procedure of SGs location update the MSC gets the last used LTE PLMN ID via TAI in SGsAP- 
LOCATION-UPDATE-REQUEST as specified in TS 29.118 [44]. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC 
shall indicate the last used LTE PLMN ID to GERAN/UTRAN to help GERAN/UTRAN to re-route the UE 



£75/ 



3GPP TS 23.272 version 1 1 .5.0 Release 11 14 ETSI TS 1 23 272 V1 1 .5.0 (201 3-06) 

back to the last used LTE PLMN by selecting the suitable dedicated target frequency list (for idle mode 
mobility) or target cell (for connected mode mobility). 

Dependent on configuration and the CS service is due to CSFB, during the CSFB procedure, when indicating the 
Equivalent PLMN list to UE via LAU Accept message, the MSC shall include the last used LTE PLMN ID. 

NOTE 1: The CS Fallback enabled MSC can also be enhanced to support ICS as defined in TS 23.292 [25] and/or 
SRVCC as defined in TS 23.216 [20]. 

NOTE 2: In order to speed up the potential LAU procedure during CS fallback the MSC may be configured to 

lower the frequency of Authentication, TMSI reallocation and Identity check for UEs that are EPS/IMSI 
attached via the SGs interface. 

NOTE 3: The MSC/VLR uses the CSMO flag in LAU and CM service request message for CS Fallback statistics. 

NOTE 4: The MSC/VLR finds out the CS service is due to CSFB via CSMO Flag or the indication from the MME 
for MO CS service and CSMT Flag for MT CS service. 

If the network supports a priority call handling, the MSC maps priority indication of the lAM message to a priority 
indication of the paging message sent over the SGs interface. 

4.3.4 E-UTRAN 

The CS fallback enabled E-UTRAN supports the following additional functions: 

Forwarding paging request for CS domain to the UE. 

Directing the UE to the target CS capable cell considering the registered PLMN ID and possibly the LAC for CS 
domain received from the MME. 

The configuration of appropriate cell reselection hysteresis at Location Area boundaries (or across the whole E- 
UTRAN) to reduce Tracking Area Update traffic. 

To facilitate the configuration of TA boundaries with LA boundaries, the E-UTRAN can gather statistics (from 
the inbound inter-RAT mobility events of all UEs) of the most common LAs indicated in the RRC signalling. 

Configuration to permit the operator to choose the target Tailback' RAT and frequency. 

For SMS over SGs, no specific E-UTRAN functionality is required. 

If the network supports CSFB priority call handling, the E-UTRAN supports the following additional functions: 

For paging message received on S 1 AP with priority indication, the E-UTRAN should provide preferential 
treatment to this request compared to other normal paging requests. 

For CS fallback SlAP message with priority indication, i.e. "CSFB High Priority", if UE is in IDLE mode, the 
eNodeB should provide preferential treatment, in allocating E-UTRAN radio bearer resources compared to other 
normal resource requests. When CSFB based on PS handover is employed, the eNodeB may forward priority 
indication to the target GERAN/UTRAN. 

4.3.5 SGSN 

If the SGSN supports ISR, SGSN shall follow the rules and procedures described in TS 23.401 [2] and TS 23.060 [3] 
with the following additions and clarifications: 

The SGSN shall not send the ISR activated indication at combined RAU/LAU procedure. 

An SGSN that supports Gs uses LAI and the TMSI based NRI as provided by the UE or LAI and a hash value from the 
IMSI to determine the VLR number as defined in TS 23.236 [23] when multiple MSC/VLRs serve the same LAI. The 
same NRI value/hash value/function is used by MME to determine the VLR number. 

Dependent on configuration and the RAU Request message is due to CSFB, when indicating the Equivalent PLMN list 
to UE via RAU Accept message, the SGSN shall include the last used LTE PLMN ID. 

NOTE: The SGSN finds out the RAU Request message is due to CSFB via the indication from the MME. 
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4.3.6 BSS 

If the BSS receives indication from the MSC that the CS service (Call, CISS or LCS) was established as a result of CS 
fallback the BSS may e.g. select to use RR Connection Release with Redirect to send the UE back to E-UTRAN at 
release of the CS service. 

Dependent on configuration and the received the LTE PLMN ID, the BSS shall take the last used LTE PLMN ID into 
account when selecting the target cell in a PS handover to E-UTRAN or the dedicated target frequency list for idle 
mode mobility to E-UTRAN in RR Connection Release procedure. 

If the network supports ISR, the CS fallback enabled BSS exhibits the following behaviour: 

Even if the network is operating in NMO II the BSS shall forward Gb interface paging messages onto the radio 
interface. The BSS in a network operating in NMO II shall not be configured to use PBCCH. 

4.3.7 RNS 

If the RNS receives indication from the MSC that the CS service (Call, CISS or LCS) was established as a result of CS 
fallback the RNS may e.g. select to use RRC Connection Release with Redirect to send the UE back to E-UTRAN at 
release of the CS service. 

Dependent on configuration and the received the LTE PLMN ID, the RNS shall take the last used LTE PLMN ID into 
account when selecting the target cell in a PS handover to E-UTRAN or the dedicated target frequency list for idle 
mode mobility to E-UTRAN in RR Connection Release procedure. 

4.4 Control plane 
4.4.1 MME - MSC Server 



SGsAP 






SGsAP 






SCTP 


SCTP 






IP 


IP 






L2 


L2 






L1 


L1 







MME 



SGs 



MSC Server 



Legend: 

SGsAP: This protocol is used to connect an MME to an MSC Server based on tine BSSAP-i-. 

Stream Control Transmission Protocol (SCTP): TInis protocol transfers signalling messages. 

Figure 4.4.1-1 : SGs Interface 

4.5 Co-existence with IMS services 

A CS Fallback and IMS capable UE shall follow the procedures for domain selection for UE originating session/calls 
according to TS 23.221 [26] 'Domain selection for UE originating sessions / calls'. 

An IMS capable UE which supports SMS over IP networks shall follow the procedures for domain selection for UE 
originating SMS according to TS 23.221 [26] 'Domain selection for UE originating SMS'. 
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4.6 Emergency Calls 

4.6.1 General 

When UE is performing CS fallback procedure for Mobile Originating Call for the purpose of emergency call, it shall 
indicate to the MME that this CS fallback request is for emergency purpose. MME also indicates to the E-UTRAN via 
the appropriate S 1 -AP message that this CS fallback procedure is for emergency purpose. If PS handover is initiated, 
E-UTRAN may indicate priority level of the CS fallback to the target RAT, as specified in TS 25.413 [29], in order to 
prepare radio resource at target RAT in appropriate way, e.g. priority allocation of the RAB resource. 

NOTE 1 : E-UTRAN may use the emergency indication for selecting a particular radio access network (2G or 3G) 
for CS emergency handling. 

Based on local operator policy, if the MSC/VLR is required to handle emergeny call setup with IMSI, the network may 
perform the additional procedure defined in clause 4.6.2. 

NOTE 2: When the target RAT for emergency call due to CSFB is selected based on cell re-selection or redirection 
by the network and the UE moves to a different LA then it is possible that the UE continues the 
emergency call setup without performing a location updating procedure. In this case, the UE performs the 
emergency call setup with IMSI. 

4.6.2 Procedures to handle emergency call setup with IMSI 

This procedure is only invoked when permitted by the operator policy. 

When MME detects that the CSFB request is due to emergency call, it shall mark the SGs association as not valid (i.e., 
move to SGs-NULL state) and continue with the CSFB procedure. If ISR is active, MME shall initiate DETACH 
REQUEST message with the detach type set to "IMSI detach" via S3 to the associated SGSN. 

NOTE: This DETACH REQUEST is to deactivate ISR in the UE so that combined EPS/IMSI TAU will always 
be performed when UE returns to E-UTRAN as described in clause 6.5. 

When MSCA^LR receives CS emergency call setup with IMSI due to CSFB and this IMSI is unknown, the MSCA^LR 
shall perform a Location Update procedure to the HLR on behalf of the UE after it successfully authenticated the UE. 

4.6a Interaction with IMS Emergency session 

If the MME receives a paging request which is not for SMS and detects that the UE currently has an ongoing IMS 
emergency session, the MME shall respond with a Paging Reject towards MSC to stop CS Paging procedure. 

NOTE: If the IMS emergency session uses dedicated emergency bearers service for the media, the MME can 
detect an ongoing IMS emergency session by the presence of at least two EPS bearers with ARP value 
reserved for emergency services (one bearer for signalling and one for media). If the network allows 
media for IMS emergency session without a dedicated bearer, the MME can only use the presence of PS 
bearer with ARP value reserved for emergency services for detection. 



4.7 CSFB Priority Call Handling 



CSFB Priority call handUng ensures that, when GERAN/UTRAN supports eMLPP service (TS 22.067 [37]), end-to-end 
priority handling is provided for both mobile originated CSFB calls by a service user in E-UTRAN and for mobile 
terminated CSFB call from a service user to a normal or service user in E-UTRAN. A service user's EPS subscription 
contains an indication of the users CS domain priority status, i.e. MPS CS Priority. If the UE is subscribed to CS 
domain priority, the UE's USIM shall belong to one of Access Class 11 to 15. 

For mobile terminated CS fallback calls from a service user, the MSC provides a priority indication to the MME along 
with a paging message. The MME shall set a priority indication to the eNodeB when requesting the eNodeB to page the 
UE if the UE is idle. For mobile originated CS fallback calls from a service user in E-UTRAN, the MME determines 
that the CSFB request requires priority handling based on the UE's MPS CS Priority. For both mobile originated and 
mobile terminated CSFB, the MME shall also provide priority indication, i.e. "CSFB High Priority", when requesting 
the eNodeB to execute the CSFB priority procedure as specified in TS 36.413 [35]. The eNodeB should handle the 
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paging message with priority and also prioritize the subsequent CS fallback procedure to GERAN/UTRAN or IxRTT. 
If PS handover to GERAN or UTRAN is initiated, E-UTRAN may forward CS fallback priority indicator to the target 
RAT, as specified in TS 25.413 [29], in order to prepare radio resource at target RAT in appropriate way, e.g. priority 
allocation of the RAB resource 

NOTE 1 : For a Mobile Terminating Call from a normal user to a service user, no special handling is required. 

4.8 CS services handling in specific cases 

4.8.1 SGs paging without LAI 

If the SGs Paging Request does not contain the LAI, and if the MME can retrieve the S-TMSI associated to the IMSI, 
the MME shall temporarily store this MSCA'LR number and force the UE to re-attach to the non-EPS services based 
on: 

If the UE is in connected mode, the MME shall send a Detach Request (IMSI Detach) to the UE as described in 

clause 5.3.2; 

If the UE is in idle mode, the MME shall send Detach Indication (Local Detach) message to the SGSN via S3 
interface if ISR is active. If the mobile reachable timer is still running the MME shall page the UE with IMSI 
and the CS indicator (for CSFB) or with S-TMSI and the PS indicator (for SMS). At the reception of Extended 
Service Request (for CSFB) or Service Request (for SMS) from the UE, the MME shall not send a SGs Service 
Request to the MSC/VLR as it normally would, but instead shall send a Detach Request (IMSI Detach) to the 
UE as described in clause 5.3.2. 

The MME shall not send IMSI Detach Indication message to the MSC/VLR in the above scenarios. 

MME shall then wait for the UE to re-attach to non-EPS services via a Tracking Area Update Request; the MME shall 
IMSI attach the UE to the MSC/VLR using the stored MSC/VLR number. After successful IMSI attach, if the paging 
timer has not expired, the MSC/VLR shall page the UE again using SGs Paging Request with LAI. 

4.8.2 Handling of SGs paging when IVIIVIE cannot retrieve the S-TIVISI 

Upon receiving SGs Paging Request, if the MME cannot retrieve the S-TMSI associated with IMSI, the MME shall 
page the UE with IMSI and PS indicator to force the UE to re-attach to EPS and non-EPS services. 



IVIobility IVIanagement 



5.1 General 

The CS fallback and SMS over SGs in EPS is realized by using the SGs interface mechanism between the MSC Server 
and the MME. The SMS over SGs NAS procedures are also used for the SMS in MME option. 

The use of the "pool-area" concept as specified in TS 23.236 [23] allows to minimize the occurrence of MSC change at 
CS fallback. 

5.1 A TAI list and LAI allocation 

For CS fallback, the fallback procedure is likely to be faster if the network can allocate a Location Area to the UE that 
is the LA of the overlapping target RAT's coverage. For this situation, the MME should avoid allocating TAI lists that 
span multiple Location Areas of the target RAT (which may be contrary to the normal usage of the "tracking area list" 
concept described in TS 23.401 [2]). 

This can be achieved by: 

configuring the E-UTRAN cell's TAI to take into account the LA boundary of the target RAT; 

the MME being configured to know which TAIs are within which LA; and 
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- the MME using the TAI of the current E-UTRAN cell to derive the LAI. 
The operator should be able to configure the MME as to whether it either: 

provides normal usage of the "tracking area list" concept, or, 

the TAI list allocation is adjusted, for CS fallback mobiles, to provide "TAJ lists that do not span multiple LAs". 
The MME may use alternative approaches for LAI and TAI list allocation. In particular, this is appropriate for: 

the case of SMS over SGs without overlapping GERAN/UTRAN coverage; and 

the case when not all MSCs in the VPLMN support the SGs interface. 

In these situations, one approach is to configure the MME to allocate a default (e.g. non-broadcast) LAI which is 
associated with a VLR that supports the SGs interface. 

If "SMS in MME" is used for a UE, then the MME shall allocate a non-broadcasted LAI (not associated with any VLR) 
and a reserved TMSI, if needed, for that UE. 



5.2 Attach procedure 



The attach procedure for the CS fallback, SMS over SGs or "SMS in MME" in EPS is realized based on the combined 
GPRS/IMSI Attach procedure specified in TS 23.060 [3]. 



UE 



MME 



1 . Attach Request 



MSC/VLR 



HSS 



2. Step 3 to step 16 of the Attach procedure specified in TS 23.401 



z 



3. Derive VLR number 



4. Location Update i Request 



2. 



5. Create SGs association 



6. Location update in CS domain 



7. Location Update 



Accept 



8. Step 17 to step 26 of the Attach procedure specified in TS 23.401 



9. Paging Request 



Figure 5.2-1 : Attach Procedure 

1) The UE initiates the attach procedure by the transmission of an Attach Request (parameters as specified in 

TS 23.401 [2] including the Attach Type, old LAI and Mobile Station Classmark 2) message to the MME. The 
Attach Type indicates that the UE requests a combined EPS/IMSI attach and informs the network that the UE is 
capable and configured to use CS fallback and/or SMS over SGs. If the UE needs SMS service but not CSFB, 
the UE shall include an "SMS-only" indication in the combined EPS/IMSI Attach Request. See clause 5.6. 

2) Step 3 to step 16 of the EPS Attach procedure are performed as specified in TS 23.401 [2] with the differences as 
described below when "SMS in MME" applies: 

- If the MME is enabled to use "SMS in MME" and the MME is not registered with an HSS for that UE (i.e. 
the MME stores no subscriber data for the UE), the MME performs a registration with HSS as described in 
Annex C, clause C.8. 
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- If the MME is enabled to use "SMS in MME" and the MME is registered with an HSS for that UE but has no 
vaUd SMS subscriber data (i.e. the MME stores subscriber data for the UE but SMS subscriber data have not 
been requested before or have been removed by the HSS), the MME may perform a re-registration with HSS 
as described in Annex C, clause C.8 to obtain SMS subscriber data and to provide the HSS with the MME 
identity to be used for MT-SMS delivery. 

If the HSS supports "SMS in MME", the HSS follows the registration procedures described in Annex C, 
clause C.8. 

If the UE subscribes the eMLPP (TS 22.067 [37]) service in the CS domain, the UE EPS subscription received 
from HSS contains MPS CS Priority which indicates the UE's CS domain priority status. 

3) If the Attach Request message includes an Attach Type indicating that the UE requests a combined EPS/IMSI 
attach, the MME allocates a new LAI for the UE as described in clause 5.1 A. 

The MME does not perform any registrations with a VLR, (i.e. it skips steps 4 to 7 and no SGs association is 
created), if the Network Access Mode information in the subscriber data indicate that the subscription has no CS 
subscriber data; or if the HSS registered the MME for "SMS in MME" for the UE as described in Annex C, 
clause C.8. 

If the registration with a VLR is required and multiple PLMNs are available for the CS domain, the MME 
performs selection of the PLMN for CS domain and CS domain operator if the selected CS network is shared 
network configuration, based on the PLMN ID contained in the current TAI, old LAI and operator selection 
policies on preferred RAT for CS domain. If the target network is a shared GERAN, the MME shall also take 
into account the UE capability of support or non-support of GERAN network sharing when selecting the PLMN 
for the CS domain as specified in TS 23.251 [42]. The PLMN selected for CS should be the same that is used for 
this UE as a target PLMN for PS handovers or for any other mobility procedures related to CSFB. The MME 
may take any access restrictions provided by the HSS into account, if the network is using separate location areas 
for GERAN and UTRAN cells. The selected PLMN ID is included in the newly allocated LAI which is sent to 
MSC/VLR in step 4 and in Attach Accept to the UE. 

The MME derives a VLR number based on the newly allocated LAI and the TMSI based NRI as provided by the 
UE or on the newly allocated LAI and an IMSI hash function defined in TS 23.236 [23]. The MME starts the 
location update procedure towards the new MSCA^LR upon receipt of the subscriber data from the HSS in 
step 2). This operation marks the MS as EPS-attached in the VLR. 

4) The MME sends a Location Update Request (new LAI, IMSI, MME name. Location Update Type, selected CS 
domain operator) message to the VLR. MME name is a FQDN string. The cases in which the MME includes the 
selected CS domain operator towards the VLR are specified in TS 23.251 [42]. 

5) The VLR creates an association with the MME by storing MME name. 

6) The VLR performs the normal subscription checks for CS and if all checks are successful performs Location 
Updating procedure in CS domain. 

For GWCN configuration, the MSC selects the core network operator as specified in TS 23.251 [42]. 

7) The VLR responds with Location Update Accept (VLR TMSI) to the MME. 

8) The EPS Attach procedure is completed by performing step 17 to step 26 as specified in TS 23.401 [2]. Attach 
Accept message includes the parameters as specified in TS 23.401 [2]: VLR TMSI and LAI as allocated in step 3 
above. The existence of LAI and VLR TMSI indicates successful attach to CS domain. 

If the UE requests combined EPS/IMSI Attach Request without the "SMS-only" indication, and if the network 
supports SGs procedures only for SMS or the network decided to provide "SMS in MME" for the UE, the MME 
shall indicate in the Attach Accept message that the IMSI attach is for "SMS-only". When the network accepts a 
combined EPS/IMSI attach without limiting to "SMS-only", the network may provide a "CSFB Not Preferred" 
indication to the UE. 

If the UE requests combined EPS/IMSI Attach Request with the "SMS-only" indication, and if the network 
supports SGs procedures only for SMS or if it supports CSFB and SMS over SGs or the network decided to 
provide "SMS in MME" for the UE, the MME shall indicate in the Attach Accept message that the IMSI attach 
is for "SMS-only". 
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If the MME provides "SMS in MME" for the UE, then the TMSI and LAI are provided as specified in 
clause C.4.2. 

The network provides the "SMS-only" or "CSFB Not Preferred" indications based on locally configured operator 
policies based on e.g. roaming agreement. 

The UE behaviour upon receiving such indications is described in TS 23.221 [26]. 

If the PLMN ID for the CS domain (included in the LAI provided to the UE) differs from the PLMN ID 
provided as part of the GUTI, the equivalent PLMNs list includes the PLMN ID for the CS domain. 

9) If the VLR has updated the SGs association and if a paging timer is still running for a MT service for this UE, 
the VLR shall repeat SGs Paging Request towards the updated SGs association. 

NOTE 2: The case of unsuccessful attach to CS domain is documented in stage 3 specifications, taking into account 
reachability for CS services of UEs that have the user preference to prioritize voice over data services and 
are not configured/supporting to use IMS voice services. 

5.3 Detach procedure 

5.3.1 UE-initiated Detach procedure 

The UE-initiated Detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the MS-Initiated 
Detach Procedure specified in TS 23.060 [3]. 



UE 



MME 



1 . Detach Request 



MSC/VLR 



HSS 



2. Step 2 to step 10 of the UE-initiated Detach procedure for E-UTRAN 
as specified in TS 23.401 



5. Detach Accept 



3a. IIVISI Detach Irdication 



3b. EPS Detach Indication 



Q4. Remove SGs 
association 



6. Step 12 to step 14 of the UE-initiated Detach procedure for E-UTRAN 
as specified in TS 23.401 



Figure 5.3.1-1: UE-initiated Detachi Procedure 

1) The UE initiates the detach procedure by the transmission of a Detach Request (parameters as specified in 
TS 23.401 [2], Detach Type) message to the MME. Detach Type indicates which type of detach is to be 
performed, i.e., IMSI Detach only, EPS Detach only or combined EPS and IMSI Detach. 

2) The UE-initiated Detach procedure for E-UTRAN is continued as specified in TS 23.401 [2]. 

3a) If the detach type indicates "IMSI Detach only" or "combined EPS and IMSI Detach", the MME sends an IMSI 
Detach Indication (IMSI) message to the MSC/VLR. 

3b) If the detach type indicates "EPS Detach only", the MME sends an EPS Detach Indication (IMSI) message to the 
MSC/VLR. 

4) The MSC/VLR removes the association with the MME. 
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5) The MME sends a Detach Accept message to the UE as specified in TS 23.401 [2]. When the UE receives the 
Detach Accept message and the Detach Type indicated "EPS Detach only" in step 1, the UE disables E-UTRAN, 
selects an appropriate GERAN or UTRAN cell. 

6) The UE-initiated Detach procedure for E-UTRAN is completed with step 12 to step 14 as specified in 
TS 23.401 [2]. 

If no SGs association exists for the UE steps 3a-4 are not executed. 

5.3.1 A UE-initiated Detacin procedure for GERAN/UTRAN witin ISR 
activated 

When ISR is activated, UE initiates detach procedure as specified in TS 23.401 [2], clause 5.3.8.2.2. The procedure is 
performed with the exception as follows: 

In step 4, the SGSN sends Detach Notification (Cause, Detach type) message to the associated MME. Cause 
indicates "IMSI Detach only" when UE performs IMSI Detach only procedure. Otherwise, Cause indicates 
"complete detach", and Detach type indicates "PS detach" in case of UE-initiated GRPS Detach only procedure, 
or indicates "combined PS/CS detach" in case of UE-initiated combined GPRS/IMSI detach procedure. If Gs 
association exists, the SGSN also sends an IMSI Detach Indication (IMSI) message or a GPRS Detach Indication 
(IMSI) message to the VLR depending on the detach type sent by the UE as specified in TS 23.060 [3], 
clause 6.6.1. 

When the MME receives the Detach Notification message, it sends an IMSI Detach Indication (IMSI) message 
to the MSCA^LR if the cause indicates "IMSI Detach only" or the detach type indicates "combined PS/CS 
detach", or sends an EPS Detach Indication (IMSI) message to the MSC/VLR if the detach type indicates "PS 
detach". 

If Cause indicates "IMSI Detach only", the MME shall not deactivate ISR and steps 5 to 9 shall be skipped. 



5.3.2 MME-initiated Detacin procedure 



The MME-initiated detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the SGSN- 
Initiated Detach Procedure specified in TS 23.060 [3]. 
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Figure 5.3.2-1: MME-initiated Detachi Procedure 

1) The MME-initiated Detach procedure is performed as specified in TS 23.401 [2]. 

2a) If EPS service is not allowed for the UE the MME sends an EPS Detach Indication (IMSI detach from EPS 
service) message to the MSC/VLR. 
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2b) If the UE is required to be IMSI detached, the MME sends an IMSI Detach Indication (IMSI) 
message to the MSC/VLR. 

3) The MSCA^LR removes the association with the MME. 

4) The MME-initiated Detach procedure is completed with step 1 1 to step 14 as specified in TS 23.401 [2]. 

5) If ISR is activated in SGSN and the UE is EMM combined procedures capable, when SGSN receives Detach 
Indication message sent from MME with "Detach Type" IE that indicates "Local Detach" or Delete Bearer 
Request message from SGW for last PDP Context, then the SGSN shall send Detach Request (IMSI Detach) to 
the UE. The SGSN turns on "EMM Combined UE Waiting Flag". When SGSN may have the capability to use 
this flag and how the SGSN uses this flag is described in clause 5.5. 

If no SGs association exists for the UE steps 2a-3 are not executed. 

5.3.2A SGSN-initiated Detach procedure with ISR activated 

When ISR is activated, SGSN initiates detach procedure as specified in TS 23.401 [2], clause 5.3.8.3A. The procedure 
is performed with the exception as follows: 

In step 4, the SGSN sends Detach Notification (Cause, Detach type) message to the associated MME. If this 
detach is local to the SGSN (e.g. implicit detach). Cause indicates local detach. Otherwise, Cause indicates 
complete detach, and Detach type indicates "PS detach". If Gs association exists, the SGSN also sends a GPRS 
Detach Indication (IMSI) message to the VLR as specified in TS 23.060 [3], clause 6.6.2.1.. 

When the MME receives the Detach Notification message, it sends an EPS Detach Indication (IMSI) message to 
the MSCA'LR if the detach type indicates "PS detach". If the cause indicates local detach, the MME shall not 
remove SGs association. 

If Cause indicates local detach, the MME deactivates ISR and steps 5 to 9 shall be skipped. 



5.3.3 HSS-initiated Detach procedure 



The HSS-initiated detach procedure for the CS fallback and SMS over SGs in EPS is realized based on the HLR- 
Initiated Detach Procedure specified in TS 23.060 [3]. 
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1 . Step 1 a to step 7b of HSS-initiated detach as specified in TS 23.401 
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Figure 5.3.3-1 : HSS-initiated Detach Procedure 

1) The HSS-initiated Detach procedure is performed as specified in TS 23.401 [2]. 

2) The MME sends an EPS Detach Indication (IMSI) message to the MSCA^LR. 

3) The MSCA^LR removes the association with the MME. 

4) The HSS-initiated Detach procedure is completed with step 8a to step 10a as specified in TS 23.401 [2]. 
If no SGs association exists for the UE steps 2-3 are not executed. 
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5.3.4 Administration of tine MME - MSC/VLR Association 

The MME - MSC/VLR association is created at the following occasions: 

- Combined EPS/ IMSI attach in clause 5.2. 
Combined TA/LA Update in clause 5.4. 

The association is updated on the following occasions: 

- When an UE changes MME. 

The MME - MSC/VLR association is removed at the following occasions: 

UE-initiated Detach in clause 5.3.1. 

MME initiated Detach in clause 5.3.2. 

HSS initiated Detach in clause 5.3.3. 

Gs association establishment in 2/3G, see TS 23.060 [3]. 

MSC/VLR receives a LA update via the A or lu interface. 

Based on configuration (e.g., if the network is not using NMO-I), MSC/VLR may remove the SGs association 
when MSC/VLR receives Relocation Complete/Handover Complete during PS to CS SRVCC from E-UTRAN, 

see TS 23.216 [20]. 

5.4 TA/LA Update procedure 

5.4.0 General 

When a CS fallback and/or SMS over SGs capable UE is EPS/IMSI attached, it initiates the combined TA/LA 
procedure based on the triggers specified in TS 23.401 [2]. 

When a CS fallback and/or SMS over SGs capable UE is not EPS/IMSI attached, it may initiate a combined TA/LA 
procedure in order to use CS Fallback or SMS over SGs services. 

5.4.1 Combined TA/LA Update Procedure 

NOTE 1: The combined TA/LA Update procedure for the CS fallback, SMS over SGs or "SMS in MME" in EPS is 
realized based on the combined RA/LA Update procedure specified in TS 23.060 [3]. 
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Figure 5.4.1-1 : Combined TA / LA Update Procedure 

1) The UE detects a change to a new TA by discovering that its current TAl is not in the list of TAIs that the UE 
registered with the network or the UE's TIN indicates the need for a TAU when re-selecting to E-UTRAN. The 
combined TA/LA Update Procedure is also performed in order to re-establish the SGs association. 

2) The UE initiates the TAU procedure by sending a TAU Request (parameters as specified in TS 23.401 [2] 
including the Update Type, old LAI and Mobile Station Classmark 2) message to the MME. The Update Type 
indicates that this is a combined Tracking Area/Location Area Update Request or a combined Tracking 
Area/Location Area Update with IMSI attach Request. If the UE needs SMS service but not CSFB, the UE shall 
include an "SMS-only" indication in the combined TA/LA Update procedure, see clause 5.6. 

3) Step 4 to step 19 of the EPS TAU procedure are performed as specified in TS 23.401 [2] with the differences as 
described below when "SMS in MME" applies: 

- If the MME is enabled to use "SMS in MME" and the MME is not registered with an HSS for that UE (i.e. 
the MME stores no subscriber data for the UE), the MME performs a registration with HSS as described in 
Annex C, clause C.8. 

- If the MME is enabled to use "SMS in MME" and the MME is registered with an HSS for that UE but has no 
valid SMS subscriber data (i.e. the MME stores subscriber data for the UE but SMS subscriber data have not 
been requested before or have been removed by the HSS), the MME may perform a re-registration with HSS 
as described in Annex C, clause C.8 to obtain SMS subscriber data and to provide the HSS with the MME 
identity to be used for MT-SMS delivery. 

If the HSS supports "SMS in MME" the HSS follows the registration procedures described in Annex C, 
clause C.8. 

The MME does not perform any registrations with a VLR, (i.e. it skips steps 4 to 6 and no SGs association is 
created), if the Network Access Mode information in the subscriber data indicate that the subscription has no CS 
subscriber data or if the HSS registered the MME for "SMS in MME" for the UE as described in Annex C, 
clause C.8. 

4) If multiple PLMNs are available for CS domain, the MME performs selection of the PLMN for CS domain and 
CS domain operator if the selected CS network is shared network configuration, based on current TAI, old LAI 
and operator selection policies on preferred RAT for CS domain. If the target network is a shared GERAN, the 
MME shall also take into account the UE capability of support or non-support of GERAN network sharing when 
selecting the PLMN for the CS domain as specified in TS 23.251 [42]. The PLMN selected for CS should be the 
same that is used for this UE as a target PLMN for PS handovers or for any other mobility procedures related to 
CSFB. The MME may take any access restrictions provided by the HSS into account, if the network is using 
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separate location areas for GERAN and UTRAN cells. The selected PLMN ID is included in the newly allocated 
LAI. If the association has to be established or if the LA changed, the new MME sends a Location Update 
Request (new LAI, IMSI, MME name. Location Update Type, selected CS domain operator) message to the 
VLR. The cases in which the MME includes the selected CS domain operator towards the VLR are specified in 
TS 23.251 [42]. The MME retrieves the corresponding VLR number from the determined LAI. If multiple 
MSC/VLRs serve this LAI, the TMSI based NRI as provided by the UE or an IMSI hash function is used to 
retrieve the VLR number for the LAI as defined in TS 23.236 [23]. The Location Update Type shall indicate 
normal location update. The MME name is a FQDN string. 

5) The VLR performs the normal subscription checks for CS and if all checks are successful performs Location 
Update procedure in CS domain. 

For GWCN configuration, the MSC selects the core network operator as specified in TS 23.251 [42]. 

6) The VLR responds with Location Update Accept (VLR TMSI) to the MME. 

7) The MME sends a TAU Accept (parameters as specified in TS 23.401 [2], LAI, VLR TMSI) message to the UE. 
The VLR TMSI is optional if the VLR has not changed. LAI is determined in step 4 above. The presence of the 
LAI indicates to the UE that it is IMSI attached. If the UE requests combined TA/LA Update Request without 
the "SMS-only" indication, and if the network supports SGs for SMS only, the network shall perform the IMSI 
attach and the MME shall indicate in the TAU Accept message that the IMSI attach is for "SMS-only". 

If the UE requests combined TA/LA Update (or combined TA/LA Update with IMSI attach) without the "SMS- 
only" indication, and if the network supports SGs procedures only for SMS or the network decided to provide 
"SMS in MME" for the UE, the MME shall indicate "SMS-only" in the TAU Accept message. However, if the 
network supports CSFB and SMS over SGs and accepts a combined TA/LA Update procedure but does not 
indicate "SMS-only", the MME may provide a "CSFB Not Preferred" indication to the UE. 

If the UE requests combined TA/LA Update (or combined TA/LA Update with IMSI attach) with the "SMS- 
only" indication, and if the network only supports SGs procedures for SMS or if it supports CSFB and SMS over 
SGs or if the network decided to provide "SMS in MME" for the UE, the MME shall indicate in the TAU Accept 
message that the combined TA/LA Update procedure is for "SMS-only". 

If the MME provides "SMS in MME" for the UE, then the TMSI and LAI are provided as specified in 
clause C.4.2. 

The network provides the "SMS-only" or "CSFB Not Preferred" indications based on locally configured operator 
policies based on e.g. roaming agreement. 

The UE behaviour upon receiving such indications is described in TS 23.221 [26]. 

If the PLMN ID for the CS domain (included in the LAI provided to the UE) differs from the PLMN ID 
provided as part of the GUTI, the equivalent PLMNs list includes the PLMN ID for the CS domain. 

8) The UE may send a TAU complete message as specified in TS 23.401 [2] for the TAU procedure. 

9) If the VLR has updated the SGs association and if a paging timer is still running for a MT service for this UE, 
the VLR shall repeat SGs Paging Request towards the updated SGs association. 

5.4.2 Periodic TA and LA Update Procedure 

When the UE is camped on E-UTRAN, periodic LA updates shall not be performed, but periodic TA updates shall be 
performed. In this case, an SGs association is established and the MSC/VLR shall disable implicit detach for EPS- 
attached UEs and instead rely on the MME to receive periodic TA updates. 

When a periodic TA update is not received in the MME, the MME clears the PPF. The lack of periodic TA update may 
be caused by reselection or handover to GERAN/UTRAN when ISR is active. To ensure CS paging can reach the 
EPS/IMSI attached UE, the UE shall perform combined RA/LA update in NMO I or LAU in NMO II when the periodic 
TAU timer expires and the UE is in GERAN/UTRAN (or next returns to coverage in GERAN/UTRAN) and ISR is 

active. 

In addition, when a periodic TA update is not received in the MME, the MME may implicitly detach the UE as 
specified in TS 23.401 [2]. This MME implicit detach does not affect any SGSN attach status. At an implicit detach, the 
MME also releases the SGs association with the MSC/VLR. The MSC continues to maintain the registered LA for the 
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UE. The MSC changes to supervise LA updates and pages in the still registered LA when mobile terminated services 
arrive. 

When the UE camps on GERAN/UTRAN it may perform combined RA/LA updates. The combined RA/LA update 
procedures and the conditions for their usage are described in TS 23.060 [3]. 

5.4.3 Non-EPS Alert procedure 

The MSC/VLR may request an MME to report activity from a specific UE. In this case, the MSCA'^LR shall send a 
SGsAP Alert Request (IMSI) message to the MME where the UE is currently EPS-attached. 

Upon reception of the SGsAP Alert Request (IMSI) message, the MME shall set NEAF (Non-EPS Alert Flag). If NEAF 
is set for an UE, the MME shall inform the MSCA^LR when the next activity from that UE (and the UE is both IMSI- 
and EPS attached) is detected, and shall clear NEAF. 

If the activity detected by the MME leads to a procedure towards the MSCA'^LR, the MME shall just follow this 
procedure. If the activity detected by the MME does not lead to any procedure towards the MSC/VLR, the MME shall 
send an UE Activity Indication (IMSI) message towards the MSCA^LR. 

5.4.4 Void 



5.5 Idle Mode Signalling Reduction 

In relation with CSFB and/or SMS over SGs, when ISR is activated, the UE follows regular ISR behaviour. It may 
reselect between E-UTRAN and GERAN/UTRAN without a need to update the CN. When a mobile terminated service 
arrives, the MSC/VLR sends a paging message via SGs to the MME. The MME pages in the TA(s) registered for the 
UE, and, the MME uses the S3 interface to request the SGSN (i.e. the SGSN that has an ISR relation with the MME for 
that UE) to page the UE in the registered RA. When the UE is already connected with the MME, the MME forwards the 
paging request only to the UE via the established signalling connection. 

When the UE is IMS registered for voice service, even if the UE is configured for CSFB or SMS over SGs, it may need 
to ignore ISR activation based on the conditions for ISR activation/de-activation for UEs registered for IMS voice 
service as defined in TS 23.401 [2]. 

A UE that supports CSFB and/or SMS over SGs includes the "EMM combined procedures capability" indication as part 
of the "MS Network Capability" in the Attach, RAU or combined RAU/LAU Request message, if the UE supports 
CSFB service or SMS over SGs. SGSN stores the "EMM combined procedures capability" indication for ISR operation 
as part of the stored "MS Network Capability". If the UE does not support CSFB or SMS over SGs, it shall not include 
the "EMM combined procedures capability" indication in the Attach, RAU or combined RAU/LAU Request message to 
SGSN. 

ISR remains activated until the UE performs a combined RAU/LAU procedure (e.g. a UE in NMO I moves to a new 
RA or LA or the periodic TAU timer expires while the UE is in NMO I of GERAN/UTRAN) or separate LAU 
procedure (e.g. a UE moves to a different LA in NMO II or the periodic TAU timer expires while the UE is in NMO II 
of GERAN/UTRAN). Normal re-selection between registered RA/TA(s) does not cause ISR deactivated condition. 
When the UE needs to perform a combined RAU/LAU, the SGSN checks the "EMM combined procedures capability" 
bit in MS Network Capability and if it indicates that CSFB and/or SMS over SGs is supported then the SGSN 
deactivates ISR by not indicating ISR activated in the combined RAU Accept message, which is a regular ISR 
functionality as specified in TS 23.401 [2]. So an SGSN in a CSFB/SMS over SGs configuration never indicates ISR 
activated in combined RAU procedures for a UE that supports CSFB/SMS over SGs. An SGSN with ISR capability in a 
CSFB/SMS over SGs configuration shall always maintain ISR by indicating ISR Activated in Periodic RAU Accept for 
a UE that supports CSFB/SMS over SGs if the SGSN has the status that ISR is activated for the UE. After a combined 
RA/LA update procedure, the MSC pages via Gs for mobile terminated services. When Gs is not used, the MSC/VLR 
pages in the LA via lu/A for mobile terminated services. 

If ISR is deactivated and the UE re-selects to E-UTRAN with the TIN indicating "P-TMSI", it initiates a TAU 
procedure, which is a regular ISR functionality as specified in TS 23.401 [2], and ISR can be activated again. The UE 
that supports CS fallback/SMS over SGs shall perform this TAU procedure as a combined TA/LA Update Procedure. 
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In case of the detach procedure for E-UTRAN when ISR is activated, the MME notifies the associated SGSN with 
indicating detach cause (i.e. local detach or complete detach) as specified in clause 5.3.1, 5.3.2, 5.3.3 and TS 23.401 [2] 
except UE-initiated IMSI detach only procedure. 

In case of the detach procedure for GERAN/UTRAN when ISR is activated, the SGSN sends an IMSI or GRPS Detach 
indication message to the VLR depending on the detach type sent by the UE as specified in TS 23.060 [3], clause 6.6.1, 
and notifies the associated MME with indicating detach cause (i.e. local detach, complete detach or IMSI detach only) 
and detach type (i.e. PS detach or combined PS/CS detach) in case of complete detach, and the MME sends IMSI 
Detach Indication or EPS Detach Indication message to the MSC/VLR accordingly, which is specified in clause 5.3.1 A 
and 5.3.2A. 

When the MME receives a SGs paging for CS service, if ISR is activated and the mobile reachable timer has expired 
but the Implicit Detach timer has not expired, the MME shall not notify the MSC/VLR that the UE is unreachable via 
SGs and instead shall page the UE via S3 interface. 

When implicit detach timer expires in the MME, the MME shall send EPS Detach Indication message. . 

The SGSN in NMO I configuration with ISR capability shall support the "EMM combined UE Waiting Flag". The 
"EMM Combined UE Waiting Flag" shall be turned on if SGSN sends Detach Request (IMSI Detach) to the UE as 
specified in clause 5.3.2. 

If "EMM Combined UE Waiting Flag" is turned on in the SGSN, then the SGSN shall behave as follows: 

- If the SGSN receives Periodic RAU from the UE, the SGSN shall send Detach Request (IMSI Detach) to the 
UE. 

If the SGSN receives Combined RAU from the UE, the SGSN shall continue the procedure as specified in 
TS 23.060 [3]. 

If the SGSN receives Service Request from the UE, the SGSN handles the Service Request normally and shall 
send Detach Request (IMSI Detach) to the UE. 

- The SGSN shall turn off the "EMM Combined UE Waiting Flag" if the SGSN receives Combined RAU from the 
UE. 

The MME should not activate ISR if "SMS in MME" for the UE is used. 

5.6 Mobility IVIanagement for SIVIS over SGs only UEs 

UEs that need SMS service but not CSFB indicate this specific condition with the "SMS-only" indication in the 
EPS/IMSI Attach Request and combined TA/LA update procedures. This allows an operator to deploy the SGs for SMS 
delivery over LTE only without the need for CSFB support. In addition, this allows the MME to use a dedicated 
algorithm for the selection of the MSC that supports those UEs. An MME that supports "SMS in MME" may directly 
handle SMS services for the UE under the conditions described in clause C.4.2. 

NOTE: SMS delivery via SGs does not cause the terminal to fallback to the CS -capable network. It is possible 

that only certain MSCs in the network (one in minimum) are configured to support SGs when the network 
only supports SMS and no other (CS) services via SGs. However such a minimal configuration can cause 
inter-MSC location updates to be performed at every movement into/out of E-UTRAN coverage. 

5.7 Access to CS services after selecting a non-3GPP access 

When a UE, which obtained voice and/or SMS services using an EPS/IMSI registration via E-UTRAN, selects a non- 
3GPP access network, the UE tries to retain these services by actions described in TS 23.221 [26], clause 7.2a. 
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Mobile Originating Call 



6.1 



General 



This clause describes the mobile originating call procedures for the CS Fallback in EPS. 

6.2 Mobile Originating call in Active Mode - PS HO supported 

This flow may be executed when the eNodeB knows that both the UE and the network support PS HO, in the normal 
case. Clause 6.6 describes the procedure when the procedure is rejected by the MME. 
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Figure 6.2-1 : CS Call Request in E-UTRAN, Call in GERAN/UTRAN 

NOTE 1: DTM is not mandatory for CS Fallback to work and is not linked to PS HO. 

la. The UE sends an Extended Service Request for mobile originating CS fallback to MME. Extended Service 
Request message is encapsulated in RRC and Sl-AP messages. The UE only transmits this request if it is 
attached to CS domain (with a combined EPS/IMSI Attach) and can not initiate an IMS voice session (because 
e.g. the UE is not IMS registered or IMS voice services are not supported by the serving IP-CAN, home PLMN 
or UE). 

lb. The MME sends an Sl-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB. 
This message indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. The registered PLMN 
for CS domain is identified by the PLMN ID included in the LAI, which is allocated by the MME. 
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If MME determines the CS Fallback procedure needs priority handling based on MPS CS Priority in the UE's 
EPS subscription, it also sets priority indication, i.e. "CSFB High Priority", in the SlAP message to the eNodeB 
as specified in TS 36.413 [35]. 

Ic. The eNodeB shall reply with Sl-AP UE Context Modification Response message. 

Id. Dependent on configuration, the MME shall send the SGs Service Request message (CS MO call indicator) to 
the MSC in order to indicate that the CM service request message, as described in step 4b in this clause, is due to 
the CSFB via CS MO call. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which PS handover will be performed. 

NOTE: Based on operator policy, the priority indicator received in steplb may be used by eNodeB to decide 

whether to continue CS Fallback procedures with PS HO, i.e. step3a, or to initiate radio release procedure 
to redirect the UE to 2G/3G Circuit Switch as specified in clause 6.3. 

3a. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required 
message to the MME. The eNodeB selects the target PS handover cell considering the PLMN ID and possibly 
the LAC for CS domain provided by the MME in step lb. 

If the eNB is a HeNB, the HeNB should perform step 3 through step 6 of clause 6.3 instead of PS HO if the 
HeNB detects that the UE has only LIPA PDN Connections. CSFB will not be completed successfully when PS 
HO is performed if the UE has only LIPA PDN Connections as PS HO would result in the MME detaching the 
UE. 

NOTE 2: For details how the HeNodeB determines whether a PDN connection is a LIPA PDN connection see 
TS 23.401 [2], clause 4.3.16. 

In the following an inter-RAT handover from E-UTRAN to UTRAN or GERAN as specified in TS 23.401 [2] 
begins. The eNodeB indicates in the Source RNC to Target RNC Transparent container that PS handover was 
triggered due to CSFB. The eNodeB also indicates whether CSFB was triggered for emergency or priority call 
handling purpose. If the network supports a priority call handling, the eNodeB may forward the priority 
indication to the target GERAN/UTRAN in the Source to Target Transparent Container, and the target 
GERAN/UTRAN allocates radio bearer resources taking received priority indication take into account. As part 
of this handover, the UE receives a HO from E-UTRAN Command and tries to connect to a cell in the target 
RAT. The HO from E-UTRAN Command may contain a CS Fallback Indicator which indicates to UE that the 
handover is triggered due to a CS fallback request. If the HO from E-UTRAN Command contains a CS Fallback 
Indicator and the UE fails to establish connection to the target RAT, then the UE considers that CS fallback has 
failed. Service Request procedure is considered to be successfully completed when PS Handover procedure is 
completed successfully. 

NOTE 3: During the PS HO the SGSN does not create a Gs association with the MSC/VLR. 

NOTE 4: Service Request procedure supervision timer shall be sufficiently long considering the optional 
measurement reporting at step 2. 

When the UE arrives at the target cell, if the target RAT is UTRAN, the UE establishes the radio signalling 
connection by sending an RRC Initial Direct Transfer message as specified in TS 25.331 [7] that contains a NAS 
message. The CN Domain Indicator is set to "CS" in the Initial Direct Transfer message. 

If the target RAT is GERAN A/Gb mode: The UE establishes a radio signalling connection by using the 
procedures specified in TS 44.018 [4] (i.e. UE requests and is assigned a dedicated channel where it sends a 
SABM containing a NAS message to the BSS and the BSS responds by sending a UA). Upon receiving the 
SABM (containing the NAS message) the BSS sends a COMPLETE LAYER 3 INFORMATION message 
(containing the NAS message) to the MSC which indicates CS resources have been allocated in the GERAN 
cell. If both the UE and the target cell support enhanced CS establishment in DTM (indicated by GERAN system 
information included within the HO from E-UTRAN Command) a RR connection may be established while in 
packet transfer mode without release of the packet resources, see TS 43.055 [24]. After the establishment of the 
main signalling link as described in TS 44.018 [4] the UE enters either Dual Transfer Mode or Dedicated Mode. 

3b. If the target RAT is GERAN and the UE has entered Dedicated Mode, the UE starts the Suspend procedure (see 
TS 44.018 [4]) unless both the UE and the Target cell support DTM in which case TBF re-establishment may be 
performed. 
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3c. A Gn/Gp-SGSN that receives the Suspend message from the UE follows the Suspend procedure specified in 
TS 23.060 [3], clause 16.2.1.1.1. 

An S4-SGSN that receives the Suspend message from the UE follows the Suspend procedure specified in 
TS 23.060 [3]. The S4-SGSN deactivates GBR bearers towards S-GW and P-GW(s) by initiating MS-and SGSN 
Initiated Bearer Deactivation procedure as specified in TS 23.060 [3], and starts the preservation and suspension 
of non-GBR bearers by sending Suspend Notification message to the S-GW. The S-GW releases all RNC related 
information (address and TEIDs) for the UE if Direct Tunnel is established, and sends Suspend Notification 
message to the P-GW(s). The SGSN stores in the UE context that UE is in suspended status. All the preserved 
non-GBR bearers are marked as suspended status in the S-GW and P-GW(s). The P-GW should discard packets 
if received for the suspended UE. 

4a. If the LA of the new cell is different from the one stored in the UE (which is received as part of Combined 
Attach/TAU procedure in E-UTRAN), the UE shall initiate a Location Area Update procedure as follows: 

if the network is operating in NMO-I (Network Modes of Operation), the UE shall initiate a separate 
Location Area Update before initiating the RAU procedure instead of a Combined RA/LA Update procedure 
(to speed up the CSFB procedure); or 

if the network is operating in NMO-II, the UE shall initiate a Location Area Update before initiating the 
RAU procedure required for PS handover. 

When the UE initiates a Location Area Update the UE shall set the "follow-on request" flag in the LAU Request 
in order to indicate to the MSC not to release the lu/A connection after the LAU procedure completion. The UE 
shall indicate to the target MSC that this is an originating call establishment as a result of CSFB by including the 
"CSMO" flag. Further the UE performs any Routing Area Update procedure as specified by TS 23.060 [3]. 

The UE may initiate a Location Area Update procedure immediately when the UE is handed over to the target 
cell i.e. before the UE receives e.g. LAI or NMO information as part of the RAN Mobility Information. 

4b. The UE sends a CM Service Request to the MSC. The UE shall indicate to the MSC that this is an originating 
call estabHshment as a result of CSFB by including the "CSMO" flag. 

5. If the UE is not registered in the MSC serving the 2G/3G target cell or the UE is not allowed in the LA, the MSC 
shall reject the CM service request, if implicit location update is not performed. The CM Service Reject shall 
trigger the UE to perform a Location Area Update or a Combined RA/LA Update procedure as specified in 

TS 23.060 [3] for the different Network Modes of Operation (NMO). 

6. The UE initiates the CS call establishment procedure and the UE shall include the CSMO flag in the CM Service 
Request to the MSC. 

7. The UE performs any remaining steps of the inter-RAT handover from E-UTRAN to UTRAN or GERAN as 
specified in TS 23.401 [2]. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21]. 

6.3 Mobile Originating call in Active Mode - No PS HO support 

This procedure is executed when PS HO is not supported, in the normal case. Clause 6.6 describes the procedure when 
the procedure is rejected by the MME. 
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Figure 6.3-1 : CS Call Request in E-UTRAN, Call in GERAN/UTRAN without PS HO 

la. The UE sends an Extended Service Request for mobile originating CS fallback to the MME. Extended Service 
Request message is encapsulated in RRC and Sl-AP messages. The UE only transmits this request if it is 
attached to CS domain (with a combined EPS/lMSl Attach) and can not initiate an IMS voice session (because 
e.g. the UE is not IMS registered or IMS voice services are not supported by the serving IP-CAN, home PLMN 
or UE). 

lb. The MME sends an Sl-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB. 
This message indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. The registered PLMN 
for CS domain is identified by the PLMN ID included in the LAI, which is allocated by the MME. 

If MME determines the CS Fallback procedure needs priority handling based on MPS CS Priority in the UE's 
EPS subscription, it sets priority indication, i.e. "CSFB High Priority", in the SlAP message to the eNodeB as 
specified in TS 36.413 [35]. 

Ic. The eNodeB shall reply with Sl-AP UE Context Modification Response message. 

Id. Dependent on configuration, the MME shall send the SGs Service Request message (CS MO call indicator) to 
the MSC in order to indicate that the CM service request message, as described in step 9 in this clause, is due to 
the CSFB via CS MO call. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which the redirection procedure will be performed. 

The network performs one of steps 3a or 3b or 3c. 

3a. If the UE and network support inter-RAT cell change order to GERAN and the target cell is GERAN: 

The eNodeB can trigger an inter-RAT cell change order (optionally with NACC) to a GERAN neighbour cell by 
sending an RRC message to the UE. The inter-RAT cell change order may contain a CS Fallback Indicator 
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which indicates to UE that the cell change order is triggered due to a CS fallback request. If the inter-RAT cell 
change order contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, then 
the UE considers that CS fallback has failed. Service Request procedure is considered to be successfully 
completed when cell change order procedure is completed successfully. 

The eNodeB selects the target cell considering the PLMN ID and possibly the LAC for CS domain provided by 
the MME in step lb for CCO/NACC purpose. 

3b. If the UE or the network does not support inter-RAT PS handover from E-UTRAN to GERAN/UTRAN nor 
inter-RAT cell change order to GERAN or the network does not wish to use these procedures: 

The eNodeB can trigger RRC connection release with redirection to GERAN or UTRAN. 

NOTE 1 : When performing CS Fallback to UTRAN, the RRC connection release with redirection can be optimized 
if both the UE and UTRAN support the optional "Deferred measurement control reading" feature 
specified in TS 25.331 [7]. 

3c. If the UE and network support "RRC connection release with redirection and Multi Cell System Information to 
GERAN/UTRAN": 

The eNodeB can trigger RRC connection release with redirection to GERAN or UTRAN and include one or 
more physical cell identities and their associated System Information. 

In step 3b or step 3c, the eNodeB includes the redirection control information into the RRC Connection Release 
message based on the PLMN ID for CS domain and the RAT/frequency priority configured in the eNodeB, so 
that the UE registered PLMN for CS domain can be preferably selected. 

NOTE 2: Service Request procedure supervision timer shall be sufficiently long considering the optional 
measurement reporting at step 2. 

4. The eNodeB sends an Sl-AP UE Context Release Request message to the MME. If the target cell is GERAN 
and either the target cell or the UE does not support DTM the message includes an indication that the UE is not 
available for the PS service. 

5. The MME releases the UE Context in the eNodeB as well as all eNodeB related information in the S-GW as 
specified in TS 23.401 [2]. 

In case the Cause indicates that RRC was released due to abnormal conditions, e.g. radio link failure, the MME 
suspends the EPS bearers (Step 8). 

The UE performs one of steps 6a or 6b or 6c and THEN performs step 6d. 

6a. (Step 6a is performed if step 3a, Cell Change Order to GERAN, was performed) 

The UE moves to the new cell in GERAN. The UE uses the NACC information and/or the broadcast System 
Information and when it has all of the necessary information to access the GERAN cell, establishes a radio 
signalling connection. 

6b. (Step 6b is performed if step 3b, RRC release with redirection, was performed). 

The UE moves to the target RAT, identifies a suitable cell preferably of the same PLMN as received in LAI IE 
of combined EPS/IMSI Attach/TAU Accept message, receives the broadcast System Information and when it 
has the necessary information to access GERAN/UTRAN, establishes a radio signalling connection. 

6c. (Step 6c is performed if step 3c, RRC connection release with redirection and Multi Cell System Information, 
was performed). 

The UE moves to the target RAT and identifies a suitable cell preferably of the same PLMN as received in LAI 
IE of combined EPS/IMSI Attach/TAU Accept message. The UE uses the Multi Cell System Information and/or 
the broadcast System Information and when it has all of the necessary information to access GERAN/UTRAN, 
the UE establishes the radio signalling connection. 

6d. When the UE arrives at the target cell, if target RAT is UTRAN: The UE establishes the radio signalling 

connection by sending an RRC Initial Direct Transfer message as specified in TS 25.331 [7] that contains a NAS 
message. The CN Domain Indicator is set to "CS" in the Initial Direct Transfer message. If the eNodeB indicated 
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UE to go to GERAN in step 3 but the UE finally camps on an UTRAN cell of the same RA that the UE is 
registered with and ISR active, the UE shall locally deactivate ISR. 

If target RAT is GERAN A/Gb mode: The UE establishes a radio signalling connection by using the procedures 
specified in TS 44.018 [4] (i.e. UE requests and is assigned a dedicated channel where it sends a SABM 
containing a NAS message to the BSS and the BSS responds by sending a UA). Upon receiving the SABM 
(containing the NAS message) the BSS sends a COMPLETE LAYER 3 INFORMATION message (containing 
the NAS message) to the MSC which indicates CS resources have been allocated in the GERAN cell. After the 
establishment of the main signalling link as described in TS 44.018 [4] the UE enters either Dual Transfer Mode 
or Dedicated Mode. 

If the LA of the new cell is different from the one stored in the UE, the UE (which is received as part of 
Combined Attach/TAU procedure in E-UTRAN) shall initiate a Location Area Update regardless of the different 
Network Modes of Operation (NMO). The UE shall set the "follow-on request" flag in the LAU Request in order 
to indicate to the MSC not to release the lu/A connection after the LAU procedure is complete. The UE shall 
indicate to the target MSC that this is an originating call establishment as a result of CSFB by including the 
CSMO flag. Further the UE performs any Routing Area Update procedure as specified by TS 23.060 [3]. 

In NMO I a CSFB UE shall perform separate LAU with "follow-on request" flag and "CSMO" flag, and RAU 
procedures instead of a Combined RA/LA Update procedure to speed up the CSFB procedure. 

7. If the target RAT is GERAN and DTM is not supported or the UE does not support DTM, the UE starts the 
Suspend procedure specified in TS 23.060 [3]. This triggers the (serving) SGSN to send a Suspend Request 
(TLLI, RAI) message to the old CN node identified by the RAI and TLLI. If ISR is not active, the RAI and TLLI 
refer to an MME. The MME returns a Suspend Response to the SGSN even though the GUTI cannot be derived 
from the P-TMSI and RAI pair. If ISR is active, the RAI and TLLI refer to the old S4-SGSN, In this case, if the 
serving SGSN is different from the old SGSN which has ISR association with MME, the old SGSN returns a 
Suspend Response to the serving SGSN. 

NOTE 3: For step 7b and 8, the inter-SGSN suspending procedure of ISR active case are not shown in the figure. 

8. If the Sl-AP UE Context Release Request message, received from the eNodeB in step 4, indicates that the UE is 
not available for the PS service in the target cell, the MME deactivates GBR bearers towards S-GW and P- 
GW(s) by initiating MME-initiated Dedicated Bearer Deactivation procedure as specified in TS 23.401 [2], and 
starts the preservation and suspension of non-GBR bearers by sending Suspend Notification message to the S- 
GW. If ISR is active, the (old) S4-SGSN deactivates GBR bearers towards S-GW and P-GW(s) by initiating MS- 
and SGSN initiated Bearer Deactivation procedure as specified in TS 23.060 [3], and starts the preservation and 
suspension of non-GBR bearers by sending the Suspend Notification message to the S-GW, which is all 
triggered by the Suspend procedure in step 7. The S-GW sends Suspend Notification message to the P-GW(s) 
when it receives the Suspend Notification message from MME or S4-SGSN. If the S-GW receives two Suspend 
Notification messages for the same UE, it ignores the second one except for sending response. The MME stores 
in the UE context that UE is suspended status. If ISR is active, the (old) S4-SGSN stores in the UE context that 
UE is in suspended status. All the preserved non-GBR bearers are marked as suspended status in the S-GW and 
P-GW(s). The P-GW should discard packets if received for the suspended UE. 

NOTE 4: Step 8 can not be triggered by the Suspend procedure since the full GUTI can not be derived from the P- 
TMSI and RAI included in the Suspend Request message. 

9. The UE continues with the MO call setup procedure with sending CM Service Request. The UE shall indicate to 
the MSC that this is an originating call establishment as a result of CSFB by including the "CSMO" flag. 

10a. If the UE is not registered in the MSC serving the 2G/3G cell or the UE is not allowed in the LA, the MSC 
shall reject the service request, if implicit location update is not performed. 

10b. A UE detecting that the MSC rejected the service request shall perform the Location Area Update or a 

Combined RA/LA procedure according to existing GERAN or UTRAN procedures as specified in TS 23.060 [3] 
for the different Network Modes of Operation (NMO). 

10c. The UE initiates the CS call establishment procedure and the UE shall include the CSMO flag in the CM 
Service Request to the MSC. 

1 1 . After the CS voice call is terminated and if the UE is in GERAN and PS services are suspended, then the UE 
shall resume PS services as specified in TS 23.060 [3]. A Gn/Gp -SGSN will follow TS 23.060 [3] to resume the 
PDP Context(s); in addition, the Gn/Gp SGSN sends a Update PDP Context Request message to the 
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GGSN/P-GW, the GGSN/P-GW resumes the PDP Context(s). An S4 SGSN will follow TS 23.060 [3] to resume 
the bearers, and informs the S-GW and P-GW(s) to resume the suspended bearers. If the UE has returned to E- 
UTRAN after the CS voice call was terminated, then the UE shall resume PS service by sending TAU to MME. 
The MME will in addition inform S-GW and P-GW(s) to resume the suspended bearers. Resuming the 
suspended bearers in the S-GW and in the P-GW should be done by implicit resume using the Modify Bearer 
request message if it is triggered by the procedure in operation, e.g. RAU, TAU or Service Request. The S-GW 
is aware of the suspend state of the bearers and will forward the Modify Bearer request to the P-GW. Explicit 
resume using the Resume Notification message should be used in cases when Modify Bearer Request is not 
triggered by the procedure in operation. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21]. 

6.4 Mobile Originating call in Idle Mode 

Mobile Originating call in Idle Mode procedure is specified by reusing the Mobile Originating Call in Active mode 
procedures as specified in clauses 6.2 and 6.3 with Extended Service Request for mobile originating CS fallback to the 
MME where the messages Sl-AP UE Context Modification Request and Response are replaced by Sl-AP Initial UE 
Context Request and Response. The LAI is included in the Sl-AP Initial UE Context Request message and sent to the 
eNodeB. The UE is transited to ECM-CONNECTED mode by following the applicable procedures specified in 
TS 23.401 [2]. 

NOTE: Even in case both the UE and the network support PS HO, the eNodeB may choose to use a different 
inter-RAT mobility procedure. 

If UE has only LIPA PDN connection and the cell accessed by the UE does not link to the L-GW where the UE had the 
LIPA PDN Connection, the MME shall reject the Extended Service Request with a reason code which results in the UE 
selecting GERAN or UTRAN as specified in TS 24.301 [34]. 

If the UE is service user with subscription to CS domain priority service, the UE will set the RRC establishment cause 
to "HighPriority Access" based on the access class as specified in TS 36.331 [33]. If the network supports a priority call 
handling, the MME determines that the Extended Service Request requires priority handling of CS Fallback based on 
the "HighPriority Access" establishment cause forwarded by eNodeB to the MME and/or MPS CS Priority in the UE's 
EPS subscription. According to operator policy, the MME may use MPS CS Priority in the UE's EPS subscription to 
verify the priority handling of the CS Fallback procedure. 

If MME decides to perform CS Fallback with priority, it sets priority indication, i.e. "CSFB High Priority", in the Sl- 
AP Initial UE Context Request message to the eNodeB as specified in TS 36.413 [35]. The eNodeB allocates radio 
bearer resources to the UE preferentially compared to other normal calls. 



6.5 Returning back to E-UTRAN 



Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS 
Fallback mechanisms are needed. 

During the release of an RR connection the MSC should indicate to GERAN/UTRAN that the RR connection (for call 
or CISS or LCS) was established as a result of CS fallback. GERAN and UTRAN may use the indication to determine 
which of the existing mechanisms that should be used to move the UE to E-UTRAN. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC shall 
further indicate to GERAN/UTRAN the last used LTE PLMN ID. GERAN and UTRAN shall take the last used LTE 
PLMN ID into account when selecting the target cell in PS handover to E-UTRAN or the dedicated target frequency list 
for idle mode mobility to E-UTRAN in RR Connection Release procedure. 

When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed according to 
the procedure shown in the figure 6.5-1 below. 
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Figure 6.5-1 : Resume Procedure returning from CS fallbacit no PS IHO 

1. The UE sends a TAU Request message, to the MME. 

2. If the UE context in the MME indicates that UE is in suspended status, the MME informs the S-GW and P- 
GW(s) to re-activate the EPS bearers for the UE. 

If the procedure triggered by the NAS message in step 1 activates Modify Bearer Request message to the S-GW, 
this message should be used as an implicit resume. The S-GW is aware of the suspend state of the bearers and 
shall forward the Modify Bearer request to the P-GW. The P-GW and S-GW shall clear the suspend state and 
confirm with Modify Bearer response to the MME. 

3. The NAS message is processed accordingly. 

6.6 Mobile Originated or Mobile terminated call rejected by the 
MME 

The MME may reject an Extended Service Request either for mobile originated or mobile terminated CSFB. The 
following procedure covers this scenario. 
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Figure 6.6-1 : CSFB MO or MT call, rejected by MME 

1 . UE is combined EPS/IMSI attached. 

2. UE makes a decision to perform a mobile originated CS call or accepts CS paging for the CS Fallback to 
GERAN/UTRAN. 

3. UE sends an Extended Service Request for mobile originating/mobile terminating CS fallback to the MME. 

4. If the MME decides to reject the Extended Service Request, the MME sends a Service Reject message to the UE. 

Steps 5 - 8 are executed when Service Reject is sent with a reason code which results in the UE selecting GERAN or 
UTRAN, as specified in TS 24.301 [34]. 

5. The UE selects GERAN or UTRAN CS Domain without waiting for RRC Release. 

6. The MME releases SI by sending the SI UE Context Release Command (Cause) message to the eNodeB. Cause 
value indicates that release is triggered due to CS Fallback procedure. 

7. If the RRC connection is not already released, the E-UTRAN sends a RRC Connection Release message to the 
UE. 

8. The E-UTRAN confirms the SI Release by returning an SI UE Context Release Complete message to the MME. 
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Mobile Terminating Call 



7.1 



General 



This clause describes the mobile terminating call procedures for the CS Fallback in EPS. 

The MSC handles the timers, queuing and retransmission for sending the SGsAP-P AGING-REQUEST message on the 
SGs interface in the same way that it handles the sending of a PAGING message on the A or lu interface. As a 
consequence, the MME and (if ISR is active) the SGSN shall not implement local retransmission schemes for this 
paging. 

7.2 Mobile Terminating call in idle mode 

The procedure for Mobile Terminating Call in idle mode is illustrated in figure 7.2-1, in the normal case. Clause 6.6 
describes the procedure when the procedure is rejected by the MME. 
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8. After the UE context setup the procedure continues as described the active 
mode mobile terminated call procedures described in Clause 7.3 and 7.4. 

If the eNodeB knows that PS HO is supported the procedure in clause 7.3 "Mobile 
Terminating call in Active Mode - PS HO supported" may be applied from step 2, in 
Clause 7.3, and onwards 

If the eNodeB knows that PS HO is not supported the procedure in clause 7.4 
"Mobile Terminating call in Active Mode - No PS HO support" shall be applied from 
step 2 in Clause 7.4, and onwards 



Figure 7.2-1 : Mobile Terminating Call in idle mode 

1. G-MSC receives lAM. 

2. G-MSC retrieves routing information of the terminating UE by Send Routing Info procedures as specified in 

TS 23.018 [5]. 

3. G-MSC sends lAM to the MSC on the terminating side as specified in TS 23.018 [5]. 



The MME receives a Paging Request (IMSI, VLR TMSI, Location Information, priority indication) message 
from the MSC over a SGs interface. IMSI is used by the MME to find the S-TMSI. If the TMSI and the LAI are 
received from the MSC/VLR, the S-TMSI is used as the paging address on the radio interface. If the TMSI is not 
received from the MSCA^LR, the IMSI shall be used as the paging address on the radio interface. If location 
information is reliably known by MME (i.e. MME stores the list of TAs), the MME shall page the UE in all the 
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TAs. If the MME does not have a stored TA list for the UE, the MME may use the location information received 
from the MSC to page the UE. 

NOTE 1: The case when LAI is not received from MSC/VLR and the case when S-TMSI is not available are 
further described in clause 4.8. 

NOTE 2: This procedure takes place before step 3, immediately after MSC receives MAP_PRN from HSS, if pre- 
paging is deployed. 

If the MME receives a Paging Request message for an UE which is considered as detach for EPS services, the 
MME sends the Paging reject message to the MSC with an appropriate cause value. This rejection triggers the 
MSC to page the UE over A or lu-cs interface. 

NOTE 3: In case of a CS fallback capable UE in NMO II, there is a case where, for example, the MME releases the 
SGs association due to the UE idle mode mobility while the VLR still maintains the SGs association. 

If the MME receives Paging Request with priority indication, e.g. eMLPP priority, from the MSC, then the 
MME processes this message and also the subsequent CS Fallback procedure preferentially compared to other 
normal procedures. 

5. If the MME did not return an "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends a Paging (as specified in TS 23.401 [2]) message to each eNodeB. The Paging 
message includes a suitable UE Identity (i.e. S-TMSI or IMSI) and a CN Domain Indicator that indicates which 
domain (CS or PS) initiated the paging message. In this case it shall be set to "CS" by the MME. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the paging to the eNodeBs and sends Paging Reject towards MSC to stop 
CS Paging procedure and this CSFB procedure stops. 

If the MME received Paging Request with priority indication in step4, the Paging message also includes priority 
indication. 

6. The radio resource part of the paging procedure takes place. The message contains a suitable UE Identity (i.e. 
S-TMSI or IMSI) and a CN Domain indicator. If eNodeB received Paging with Priority Indication in step 5, it 
performs the paging procedure preferentially compared to other normal paging. 

7a. The UE establishes an RRC connection and sends an Extended Service Request for mobile terminating CS 

fallback to MME. The UE indicates its S-TMSI in the RRC signalling. The Extended Service Request message is 
encapsulated in RRC and Sl-AP messages. The MME sends the SGs Service Request message to the MSC 
containing an indication that the UE was in idle mode (and hence, for example, that the UE has not received any 
Calling Line Identification information). Receipt of the SGs Service Request message stops the MSC 
retransmitting the SGs interface Paging message. 

NOTE 4: In order to avoid the calling party experiencing a potentially long period of silence, the MSC may use the 
SGs Service Request message containing the idle mode indication as a trigger to inform the calling party 
that the call is progressing. 

If the MME had received paging request with Priority Indication in step4 and receives subsequent Extended 
Service Request in Step 7a, it detects this message is the response to the priority CS Fallback procedure initiated 
in step5. In this case, the MME processes this message with priority and set the priority indication, i.e. "CSFB 
High Priority", in step7b as specified in TS 36.413 [35]. 

If UE has only LIPA PDN connection and the cell accessed by the UE does not link to the L-GW where the UE 
had the LIPA PDN Connection, the MME shall reject the Extended Service Request with a reason code which 
results in the UE selecting GERAN or UTRAN as specified in TS 24.301 [34]. 

7b. MME sends Sl-AP: Initial UE Context Setup (UE capabilities, CS Fallback Indicator, LAI and other parameters 
specified in TS 23.401 [2]) to indicate the eNodeB to move the UE to UTRAN/GERAN. The registered PLMN 
for CS domain is identified by the PLMN ID included in the LAI, which is allocated by the MME. 

7c. The eNodeB shall reply with Sl-AP: Initial UE Context Setup Response message. 

8a. If the eNodeB knows that both the UE and the network support PS handover: The information flow may 

continue as described in clause 7.3 "Mobile Terminating call in Active Mode - PS HO supported" from step 2, in 
clause 7.3, and onwards. 
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If the eNodeB knows that either the UE or the network does not support PS handover: The information flow 
shall continue as described in clause 7.4 "Mobile Terminating call in Active Mode - No PS HO support" from 
step 2, in clause 7.4, and onwards. 

NOTE 5: Even in case both the UE and the network support PS HO, the eNodeB may choose to use a different 
inter-RAT mobility procedure. 

7.3 Mobile Terminating call in Active IVIode - PS HO supported 

This flow may be executed when the eNodeB knows that both the UE and the network support PS HO in the normal 
case. Clause 6.6 describes the procedure when the procedure is rejected by the MME. 
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Figure 7.3-1 : CS Page in E-UTRAN, Call in GERAN/UTRAN 

la. The MSC receives an incoming voice call and responds by sending a Paging Request (IMSI or TMSI, optional 
Caller Line Identification and Connection Management information, CS call indicator, priority indication) to the 
MME over a SGs interface. The MSC only sends a CS Page for an UE that provides location update information 
using the SGs interface. In active mode the MME has an established SI connection and if the MME did not 
return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update procedures, the MME 
reuses the existing connection to relay the CS Page to the UE. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the CS Service Notification to the UE and shall send Paging Reject towards 
MSC to stop CS Paging procedure, and this CSFB procedure stops. 

The eNodeB forwards the paging message to the UE. The message contains CN Domain indicator and, if 
received from the MSC, the Caller Line Identification. 
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The MME immediately sends the SGs Service Request message to the MSC containing an indication that the UE 
was in connected mode. The MSC uses this connected mode indication to start the Call Forwarding on No Reply 
timer for that UE and the MSC should send an indication of user alerting to the calling party. Receipt of the SGs 
Service Request message stops the MSC retransmitting the SGs interface Paging message. 

NOTE 1 : The pre-configured policy may be used by UE to avoid being disturbed without Caller Line Identification 
display and the detailed handling is to be decided by CTl and CT6. 

NOTE 2: This procedure can also take place immediately after MSC receives MAP_PRN from HSS, if pre-paging 
is deployed. Caller Line Identification and CS call indicator are also provided in the case of pre-paging. 

NOTE 3: In order to avoid the calling party experiencing a potentially long period of silence, the MSC may use the 
SGs Service Request message as a trigger to inform the calling party that the call is progressing. 

If the MME receives paging request message with priority indication, e.g. eMLPP priority, from the MSC, then 
the MME processes this message and also the subsequent CS fallback procedure preferentially compared to other 
normal procedures. 

lb. UE sends an Extended Service Request (Reject or Accept) message to the MME for mobile terminating CS 
fallback. The Extended Service Request message is encapsulated in RRC and Sl-AP messages. The UE may 
decide to reject CSFB based on Caller Line Identification. 

Ic. Upon receiving the Extended Service Request (Reject) for mobile terminating CS fallback, the MME sends 
Paging Reject towards MSC to stop CS Paging procedure and this CSFB procedure stops. 

Id. MME sends an Sl-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB. This 
message: indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. The registered PLMN for 
CS domain is identified by the PLMN ID included in the LAI, which is allocated by the MME. 

If MME received priority indication in Step la, the MME sends Sl-AP UE Context Modification Request 
message to the eNodeB with priority indication, i.e. "CSFB High Priority", as specified in TS 36.413 [35]. 

le. The eNodeB shall reply with Sl-AP UE Context Modification Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which PS handover will be performed. 

NOTE 4: Based on operator policy, the priority indicator received in step lb may be used by eNodeB to decide 

whether to continue CS Fallback procedures with PS HO, i.e. step3a, or to initiate radio release procedure 
to redirect the UE to 2G/3G Circuit Switch. 

3a. The eNodeB triggers PS handover to a GERAN/UTRAN neighbour cell by sending a Handover Required 
message to MME. The eNodeB selects the target PS handover cell considering the PLMN ID and possibly the 
LAC for CS domain provided by the MME in step Id. 

If the eNB is a HeNB, the HeNB should perform step 3 through step 6 of clause 7.4 instead of PS HO if the 
HeNB detects that the UE has only LIPA PDN Connections. CSFB will not be completed successfully when PS 
HO is performed if the UE has only LIPA PDN Connections as PS HO would result in the MME detaching the 
UE. 

NOTE 5: For details how the HeNodeB determines whether a PDN connection is a LIPA PDN connection see 

TS 23.401 [2], clause 4.3.16. 

In the following an inter-RAT handover from E-UTRAN to UTRAN or GERAN as specified in TS 23.401 [2] 
begins. The eNodeB indicates in the Source RNC to Target RNC Transparent container that PS handover was 
triggered due to CSFB. The eNodeB also indicates whether CSFB was triggered for emergency or priority call 
handling purpose. If the network supports a priority call handling, the eNodeB may forward the priority 
indication to the target GERAN/UTRAN in the Source to Target Transparent Container, and the target 
GERAN/UTRAN allocates radio bearer resources taking received priority indication take into account. As part 
of this handover, the UE receives a HO from E-UTRAN Command and tries to connect to a cell in the target 
RAT. The HO from E-UTRAN Command may contain a CS Fallback Indicator which indicates to UE that the 
handover was triggered due to a CS fallback request. If the HO from E-UTRAN Command contains a CS 
Fallback Indicator and the UE fails to establish connection to the target RAT, then the UE considers that CS 
fallback has failed. 
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The UE establishes the signalling connection as described in step 4b. 

NOTE 6: During the PS HO the SGSN does not create a Gs association with the MSC/VLR. 

3b. If the target RAT is GERAN and the UE has entered Dedicated Mode, the UE starts the Suspend procedure (see 
TS 44.018 [4]) unless both the UE and the Target cell support DTM in which case TBF re-establishment may be 
performed. 

3c. A Gn/Gp-SGSN that receives the Suspend message from the UE follows the Suspend procedure specified in 
TS 23.060 [3], clause 16.2.1.1.1. 

An S4-SGSN that receives the Suspend message from the UE follows the Suspend procedure specified in 
TS 23.060 [3]. The S4-SGSN deactivates GBR bearers towards S-GW and P-GW(s) by initiating MS-and SGSN 
Initiated Bearer Deactivation procedure as specified in TS 23.060 [3], and starts the preservation and suspension 
of non-GBR bearers by sending Suspend Notification message to the S-GW. The S-GW releases all RNC related 
information (address and TEIDs) for the UE if Direct Tunnel is established, and sends Suspend Notification 
message to the P-GW(s). The SGSN stores in the UE context that UE is in suspended status. All the preserved 
non-GBR bearers are marked as suspended status in the S-GW and P-GW(s). The P-GW should discard packets 
if received for the suspended UE. 

4a. If the LA of the new cell is different from the one stored in the UE, the UE shall initiate a Location Area Update 
procedure as follows: 

If the network is operating in NMO-I (Network Modes of Operation), the UE shall initiate a separate 
Location Area Update before initiating the RAU procedure instead of a Combined RA/LA Update procedure 
(to speed up the CSFB procedure); or 

if the network is operating in NMO-II the UE shall initiate a Location Area Update procedure before 
initiating the RAU procedure required for PS handover. 

The UE shall set the "CSMT" flag in the LAU Request. The "CSMT" flag is used to avoid missing MT call in 
roaming retry case. Further the UE performs any Routing Area Update procedure as specified in TS 23.060 [3]. 

The UE may initiate a Location Area Update procedure immediately when the UE is handed over to the target 
cell i.e. before the UE receives e.g. LAI or NMO information as part of the RAN Mobility Information. 

When the MSC receives a LA Update Request, it shall check for pending terminating CS calls and, if the 
"CSMT" flag is set, maintain the CS signalling connection after the Location Area Update procedure for pending 
terminating CS calls. 

4b. If the UE does not initiate a LAU procedure, it shall respond with a Paging Response message to the MSC as 
follows: 

If the Target RAT is UTRAN or GERAN lu mode: The UE establishes a radio signalling connection and 
responds to the paging by sending an RRC Paging Response as specified in TS 25.331 [7]. The CN Domain 
Indicator is set to "CS" in the Initial Direct Transfer message. 

If the Target RAT is GERAN A/Gb mode: The UE establishes a radio signalling connection and responds to 
paging by using the procedures specified in TS 44.018 [4] (i.e. UE requests and is assigned a dedicated 
channel where it sends a SABM containing a Paging Response to the BSS and the BSS responds by sending 
a UA). Upon receiving the SABM (containing a Paging Response message) the BSS sends a COMPLETE 
LAYER 3 INFORMATION message (containing a Paging Response message) to the MSC which indicates 
CS resources have been allocated in the GERAN cell. If both the UE and the target cell support enhanced CS 
establishment in DTM (indicated by GERAN system information included within the HO from E-UTRAN 
Command) an RR connection may be established while in packet transfer mode without release of the packet 
resources, see TS 43.055 [24]. After the establishment of the main signalling link as described in 
TS 44.018 [4] the UE enters either Dual Transfer Mode or Dedicated Mode and the CS call establishment 
procedure completes. 

NOTE 7: The BSS should be prepared to receive a Paging Response even when the corresponding Paging Request 
has not been sent by this BSS. 

5a. After performing the LAU procedure or after receiving the Paging Response the MSC shall establish the CS call 
if the UE is allowed in the LA. 
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5b. If the UE is not registered in the MSC that receives the Paging Response or the UE is not allowed in the LA, the 
MSC shall reject the Paging Response message by releasing the A/Iu-CS. The BSC/RNC in turn releases the 
signalling connection for UTRAN or GERAN CS domain. The signalling connection release shall trigger the UE 
to obtain the LAI, which causes the initiation of a Location Area Update or a Combined RA/LA procedure as 
specified in TS 23.060 [3] for the different Network Modes of Operation (NMO). 

The Location Area Update triggers the Roaming Retry for CS Fallback procedure as defined in clause 7.5. 

5c. After performing the LAU procedure the MSC shall establish the CS call if the UE is allowed in the LA. 

6. The UE performs any remaining steps of the inter-RAT handover from E-UTRAN to UTRAN or GERAN as 
specified in TS 23.401 [2] 

With the exception of steps la and Ic, above. Call Forwarding (see TS 23.082 [31]) is performed on the basis of the 
TS 24.008 [21] signalling received on the GERAN/UTRAN cell. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21]. 

7.4 Mobile Terminating call in Active Mode - No PS HO support 

This procedure is executed when PS HO is not supported, in the normal case. Clause 6.6 describes the procedure when 
the procedure is rejected by the MME. 
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Figure 7.4-1 : CS Page in E-UTRAN, Call in GERAN/UTRAN without PS HO 

la. The MSC receives an incoming voice call and responds by sending a Paging Request (IMSI or TMSI, optional 
Caller Line Identification and Connection Management information, priority indication) to the MME over a SGs 
interface. The MSC only sends a CS Page for an UE that provides location update information using the SGs 
interface. In active mode the MME has an established SI connection and if the MME did not return the "SMS- 
only" indication to the UE during Attach or Combined TA/LA Update procedures, the MME reuses the existing 
connection to relay the CS Service Notification to the UE. 
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If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the CS Page to the UE and sends CS Paging Reject towards MSC to stop 
CS Paging procedure, and this CSFB procedure stops. 

The eNodeB forwards the paging message to the UE. The message contains CN Domain indicator and, if 
received from the MSC, the Caller Line Identification. 

The MME immediately sends the SGs Service Request message to the MSC containing an indication that the UE 
was in connected mode. The MSC uses this connected mode indication to start the Call Forwarding on No Reply 
timer for that UE and the MSC should send an indication of user alerting to the calling party. Receipt of the SGs 
Service Request message stops the MSC retransmitting the SGs interface Paging message. 

NOTE 1 : The pre-configured policy may be used by UE to avoid being disturbed without Caller Line Identification 
display and the detailed handling is to be decided by CT WGl and CT WG6. 

NOTE 2: This procedure can also take place immediately after MSC receives MAP_PRN from HSS, if pre-paging 
is deployed. Caller Line Identification is also provided in the case of pre-paging. 

If the MME receives paging request message with priority indication, e.g. eMLPP priority, from the MSC, then 
the MME processes this message and also the subsequent CS fallback procedure preferentially compared to other 
normal procedures. 

lb. UE sends an Extended Service Request (Reject or Accept) message to the MME for mobile terminating CS 
fallback. Extended Service Request message is encapsulated in RRC and Sl-AP messages. The UE may decide 
to reject CSFB based on Caller Line Identification. 

Ic. Upon receiving the Extended Service Request (Reject) for mobile terminating CS fallback, the MME sends 
Paging Reject towards MSC to stop CS Paging procedure and this CSFB procedure stops. 

Id. The MME sends an Sl-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB. 
This message indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. The registered PLMN 
for CS domain is identified by the PLMN ID included in the LAI, which is allocated by the MME. 

If MME received priority indication in Step la, the MME sends Sl-AP UE Context Modification Request 
message to the eNodeB with priority indication, i.e. "CSFB High Priority", as specified in TS 36.413 [35]. 

le. The eNodeB shall reply with Sl-AP UE Context Modification Response message. 

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN 
cell to which the redirection procedure will be performed. 

The network performs one of steps 3a or 3b or 3c. 

3a. If the UE and network support inter-RAT cell change order to GERAN and the target cell is GERAN: 

The eNodeB can trigger an inter-RAT cell change order (optionally with NACC) to a GERAN neighbour cell by 
sending an RRC message to the UE. The inter-RAT cell change order may contain a CS Fallback Indicator 
which indicates to UE that the cell change order is triggered due to a CS fallback request. If the inter-RAT cell 
change order contains a CS Fallback Indicator and the UE fails to establish connection to the target RAT, then 
the UE considers that CS fallback has failed. Service Request procedure is considered to be successfully 
completed when cell change order procedure is completed successfully. 

The eNodeB selects the target cell considering the PLMN ID and possibly the LAC for CS domain provided by 
the MME in step Id for CCO/NACC purpose. 

3b. If the UE or the network does not support inter-RAT PS handover from E-UTRAN to GERAN/UTRAN nor 
inter-RAT cell change order to GERAN: 

The eNodeB can trigger RRC connection release with redirection to GERAN or UTRAN instead of PS HO or 
NACC. 

NOTE 3: When performing CS Fallback to UTRAN, the RRC connection release with redirection can be optimized 
if both the UE and UTRAN support the optional "Deferred measurement control reading" feature 
specified in TS 25.331 [7]. 
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3c. If the UE and network support "RRC connection release with redirection and Multi Cell System Information to 
GERAN/UTRAN": 

The eNodeB can trigger RRC connection release with redirection to GERAN or UTRAN and include one or 
more physical cell identities and their associated System Information. 

In step 3b or step 3c, the eNodeB includes the redirection control information into the RRC Connection Release 
message based on the PLMN ID for CS domain and the RAT/frequency priority configured in the eNodeB, so 
that the UE registered PLMN for CS domain can be preferably selected. 

Also in Steps 3b or 3c, the eNB sets the "CS Fallback High Priority" indication in the RRC Release message, if 
the SlAP message in Step Id contains the "CSFB High Priority" indication. 

NOTE 4: Service Request procedure supervision timer shall be sufficiently long considering the optional 
measurement reporting at step 2. 

4. The eNodeB sends an Sl-AP UE Context Release Request message to the MME. If the target cell is GERAN 
and either the target cell or the UE does not support DTM the message includes an indication that the UE is not 
available for PS service. 

5. The MME releases the UE Context in the eNodeB as well as all eNodeB related information in the S-GW as 
specified in TS 23.401 [2]. 

In case the Cause indicates that RRC was released due to abnormal conditions, e.g. radio link failure, the MME 
suspends the EPS bearers (Step 8). 

The UE performs one of steps 6a or 6b or 6c and THEN performs step 6d. 

6a. (Step 6a is performed if step 3a, Cell Change Order to GERAN, was performed). 

The UE moves to the new cell in GERAN. The UE uses the NACC information and/or the broadcast System 
Information and when it has the necessary information to access the GERAN cell, establishes a radio signalling 
connection. 

6b. (Step 6b is performed if step 3b, RRC release with redirection, was performed). 

The UE moves to the target RAT, identifies a suitable cell preferably of the same PLMN as received in LAI IE 
of combined EPS/IMSI Attach/TAU Accept message,, receives the broadcast System Information and when it 
has the necessary information to access GERAN/UTRAN, establishes a radio signalling connection. 

6c. (Step 6c is performed if step 3c, RRC connection release with redirection and Multi Cell System Information, 
was performed) 

The UE moves to the target RAT and identifies a suitable cell preferably of the same PLMN as received in LAI 
IE of combined EPS/IMSI Attach/TAU Accept message. The UE uses the Multi Cell System Information and/or 
the broadcast System Information and when it has the necessary information to access GERAN/UTRAN, the UE 
establishes the radio signalling connection. 

If the UE receives the "CS Fallback High Priority" indication in the RRC Release message in Step 3b or 3c and 
the target is UTRAN, the UE sets the establishment cause value to "Terminating High Priority Signalling" in the 
RRC Connection Request in Steps 6b and 6c. If the target is GERAN, no special establishment cause value is set 
by the UE. 

6d. If the LA of the new cell is different from the one stored in the UE, the UE shall initiate a Location Area Update 
regardless of the different Network Modes of Operation (NMO). The UE shall set the "CSMT" flag in the LAU 
Request. The "CSMT" flag is used to avoid missing MT call in roaming retry case. In NMO I, the UE in 
GERAN may perform LA update over the RR connection instead of combined RA/LA update over the packet 
access as defined in TS 24.008 [21], clause 4.7.5.2.5, unless enhanced CS establishment in DTM is supported. 
Further the UE performs any Routing Area Update procedure as specified in TS 23.060 [3]. 

In NMO I a CSFB UE shall perform LAU (and if it does so, shall set the "CSMT" flag) and RAU procedures 
instead of a Combined RA/LA Update procedure to speed up the CSFB procedure. 

When the MSC receives a LA Update Request, it shall check for pending terminating CS calls and, if the 
"CSMT" flag is set, maintain the CS signalling connection after the Location Area Update procedure for pending 
terminating CS calls. 
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If the eNodeB indicated UE to go to GERAN in step 3 but the UE finally camps on an UTRAN cell of the same 
RA that the UE is registered with and ISR active, the UE shall locally deactivate ISR. 

7. If the target RAT is GERAN and DTM is not supported or the UE does not support DTM, the UE starts the 
Suspend procedure specified in TS 23.060 [3]. This triggers the (serving) SGSN to send a Suspend Request 
(TLLI, RAI) message to the old CN node identified by the RAI and TLLI. If ISR is not active, the RAI and TLLI 
refer to an MME. The MME returns a Suspend Response to the SGSN even though GUTI cannot be derived 
from the P-TMSI and RAI pair. If ISR is active, the RAI and TLLI refer to the old S4-SGSN, In this case, if the 
serving SGSN is different from the old SGSN which has ISR association with MME, the old SGSN returns a 
Suspend Response to the serving SGSN. 

NOTE 5: For step 7b and 8, the inter-SGSN suspending procedure of ISR active case are not shown in the figure. 

8. If the Sl-AP UE Context Release Request message, received from the eNodeB in step 4, indicates that the UE is 
not available for the PS services in the target cell, the MME deactivates GBR bearers towards S-GW and P- 
GW(s) by initiating MME-initiated Dedicated Bearer Deactivation procedure as specified in TS 23.401 [2], and 
starts the preservation and suspension of non-GBR bearers by sending Suspend Notification message to the S- 
GW. If ISR is active, the (old) S4-SGSN deactivates GBR bearers towards S-GW and P-GW(s) by initiating MS- 
and SGSN initiated Bearer Deactivation procedure as specified in TS 23.060 [3], and starts the preservation and 
suspension of non-GBR bearers by sending the Suspend Notification message to the S-GW, which is all 
triggered by the Suspend procedure in step 7. The S-GW sends Suspend Notification message to the P-GW(s) 
when it receives the Suspend Notification message from MME or S4-SGSN. If the S-GW receives two Suspend 
Notification messages for the same UE, it ignores the second one except for sending response. The MME stores 
in the UE context that the UE is in suspended status. If ISR is active, the (old) S4-SGSN stores in the UE context 
that UE is in suspended status. All the preserved non-GBR bearers are marked as suspended status in the S-GW 
and P-GW(s). The P-GW should discard packets if received for the suspended UE. 

NOTE 6: Step 8 can not be triggered by the Suspend procedure since the full GUTI can not be derived from the 
P-TMSI and RAI included in the Suspend Request message. 

9. If the UE does not initiate a LAU procedure, the UE responds to the paging by sending a Paging Response 
message as specified in TS 44.018 [4] or TS 25.331 [7]. When received at the BSS/RNS, the Paging Response is 
forwarded to the MSC. 

NOTE 7: The MSC should be prepared to receive a Paging Response after a relatively long time from when the CS 
Paging Request was sent (step la). 

9a. If UE is registered in the MSC serving the 2G/3G cell and the UE is allowed in the LA the MSC shall establish 
the CS call. 

9b. If the UE is not registered in the MSC that receives the Paging Response or the UE is not allowed in the LA, the 
MSC shall reject the Paging Response by releasing the A/Iu-cs connection. The BSS/RNS in turn releases the 
signalling connection for CS domain. 

9c. The signalling connection release shall trigger the UE to obtain the LAI, which causes the initiation of a 

Location Area Update or a Combined RA/LA procedure as specified in TS 23.060 [3] for the different Network 
Modes of Operation (NMO). 

The Location Area Update triggers the Roaming Retry for CS Fallback procedure as defined in clause 7.5. 

After performing the LAU procedure the MSC shall establish the CS call if the UE is allowed in the LA. 

With the exception of steps la and Ic, above. Call Forwarding (see TS 23.082 [31]) is performed on the basis of the 
TS 24.008 [21] signalling received on the GERAN/UTRAN cell. 

After the CS voice call is terminated and if the UE is still in GERAN and PS services are suspended, then the UE shall 
resume PS services as specified in TS 23.060 [3]. A Gn/Gp- SGSN will follow TS 23.060 [3] to resume the PDP 
Context(s), which is done by the Routing Area Update procedure. During the Routing Area Update procedure in which 
the Gn/Gp SGSN sends a Update PDP Context Request message to the GGSN/P-GW, the GGSN/P-GW resumes the 
PDP Context(s). An S4 SGSN will follow TS 23.060 [3] to resume the bearers, and informs the S-GW and P-GW(s) to 
resume the suspended bearers. If the UE has returned to E-UTRAN after the CS voice call was terminated, then the UE 
shall resume PS service by sending TAU to MME. The MME will in addition inform S-GW and P-GW(s) to resume the 
suspended bearers. Resuming the suspended bearers in the S-GW and in the P-GW should be done by implicit resume 
using the Modify Bearer request message if it is triggered by the procedure in operation e.g. RAU, TAU or Service 
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Request. The S-GW is aware of the suspend state of the bearers and shall forward the Modify Bearer request to the P- 
GW. Explicit resume using the Resume Notification message should be used in cases when Modify Bearer Request is 
not triggered by the procedure in operation. 

If the UE remains on UTRAN/GERAN after the CS voice call is terminated the UE performs normal mobility 
management procedures as defined in TS 23.060 [3] and TS 24.008 [21]. 



7.5 Roaming Retry for CS fallback 



The procedure in this section may be applied for mobile terminated calls where the MSC, to which the UE sends the 
LAU, is different from the MSC that sent the paging message to the UE. The procedure is based on the 'Mobile 
Terminating Roaming Retry Call' procedure defined in TS 23.018 [5] and there is an only minor adaptation of the 
procedure to support CS fallback. 
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Figure 7.5-1 : Roaming Retry for CS fallbacic 

There are only 2 differences in this procedure compared to the 'Mobile Terminating Roaming Retry Call' procedure 
defined in TS 23.018 [5]. 
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The first difference is that the paging message in E-UTRAN triggers the CS fallback which is followed by a 
location update in the new RAT. This functionality is already supported in the CS fallback flows for terminating 
calls and no additional functionality is needed. 

The second difference is that the UE includes the "CSMT" flag in the location update request message so that the 
signalling link is maintained for longer in case the lAM is delayed by the HLR. 

NOTE: Roaming Retry for CS fallback procedure is not designed to provide the target MSCA'^LR with the 

information required for allowing UE return to the last used LTE PLMN after CSFB. If this is required 
for a certain deployment, Roaming Forwarding for CS fallback could be used. 

7.5a Roaming Forwarding for CS fallback 

The procedure in this clause may be applied for mobile terminated calls where the MSC/VLR, to which the UE sends 
the LAU, is different from the MSC/VLR that sent the paging message to the UE. The procedure is based on the 
"Mobile Terminating Roaming Forwarding" procedure defined in TS 23.018 [5]; the specific behaviour for CSFB is 
described in this section. This procedure avoids impacting all GMSC nodes and can coexist with Mobile Terminating 
Roaming Retry procedure described in clause 7.5. 

NOTE 1 : In order to support Mobile Terminating Roaming Forwarding both the MSC controlling the target cell, 
the MSC that sent the paging message to the UE and the HLR need to support the feature. 

NOTE 2: This procedure has smaller call setup delay than Mobile Terminating Roaming Retry procedure especially 
in roaming cases. 

NOTE 3: If the network does not support this procedure, the Mobile Terminating Roaming Retry procedure 
specified in clause 7.5 can be used. 

In order to ensure roaming forwarding can be offered in all scenarios (e.g. in case of IMSI in the LAU Request from 
UE), HLRs should be updated to support MTRF. In order to permit Mobile Terminating Roaming Forwarding from the 
old VLR if the HLR is not updated to support MTRF but the visited network does support MTRF, the new VLR may 
include MTRF supported flag in Send Identification when it receives a Location Updating Request containing the 
"CSMT" flag. 
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Figure 7.5a-1 : Roaming Forwarding for CSFB 

The main differences compared to the "Mobile Terminating Roaming Forwarding" procedure defined in TS 23.018 [5] 
are described below: 

The paging message in E-UTRAN triggers the CS fallback which is followed by a location update in the new 
RAT. 

NOTE 4: This functionality is already supported in the CS fallback flows for terminating calls and no additional 
functionality is needed. 
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The UE includes the "CSMT" flag in the location update request message so that the signalling link is 
maintained for longer in case the lAM is delayed by the old MSCA'LR. 

- If the Location Update Request contains the "CSMT" flag set and a valid TMSI/old LAI, the new MSC/VLR 
may indicate to the old MSC/VLR that it supports MTRF in the Send Identification message. The new VLR then 
performs authentication to the Location update and updates the HSS. If the Location Update Request contains 
the IMSI, only HLR-based MTRF procedure can be used. 

After Cancel Location is received from HSS, if the HLR authorised the MTRF call between the old and the new 
terminating MSCs or if the HLR did not disallow the MTRF call between the old and the new terminating MSCs 
but the new MSC/VLR indicated its MTRF support earlier in Send Identification message, the old MSC/VLR 
stops paging timer and checks roaming and charging pre-configured agreements with regards to call routeing to 
the new MSC/VLR. If these checks are successful, the old MSC/VLR sends a Provide Roaming Number request 
(MTRF Indicator, parameters received from the HLR) to the new MSC/VLR. 

In a MT CSFB call, last used LTE PLMN identity may be added in the Provide Roaming Number Request 
message from old MSC/VLR to new MSC/VLR, based on configuration. 

7.5b Coexistence of Roaming Retry and Roaming Forwarding for 
CS fallback 

If an MSC/VLR supports both the procedures as specified in clause 7.5 and 7.5a, and the GMSC has indicated support 
roaming retry as specified in clause 7.5, the old MSC/VLR which sends the initial paging request can decide based on 
operator policy whether to follow the procedure specified in clause 7.5 or clause 7.5a. 



7.6 Returning back to E-UTRAN 



Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS 
Fallback mechanisms are needed. 

During the release of an RR connection the MSC should indicate to GERAN/UTRAN that the RR connection (for call 
or CISS or LCS) was established as a result of CS fallback. GERAN and UTRAN may use the indication to determine 
which of the existing mechanisms that should be used to move the UE to E-UTRAN. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC shall 
further indicate to GERAN/UTRAN the last used LTE PLMN ID. GERAN and UTRAN shall take the last used LTE 
PLMN ID into account when selecting the target cell in PS handover to E-UTRAN or the dedicated target frequency list 
for idle mode mobility to E-UTRAN in RR Connection Release procedure. 

When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed as specified 
in clause 6.5. 

7.7 Interaction with ISR 
7.7.1 Void 
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7.7.2 Mobile Terminating Call when ISR is active and SGs is active 
between MSC/VLR and MME 
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Figure 7.7.2-1 : Mobile Terminating Call when ISR is active and SGs is active between MSC/VLR and 

MME 

1) G-MSC receives lAM. 

2) G-MSC retrieves routing information of the terminating UE by Send Routing Info procedures as specified in 

TS 23.018 [5]. 

3) G-MSC sends lAM to the MSCA^LR on the terminating side as specified in TS 23.018 [5]. 

4) The MSCA'^LR sends a Page message to the MME via SGs (details on the Page message can be found in 
clauses 7.2 or 7.3). 

5a) The MME receives the Page message from the MSCA^LR. If the UE is in ECM-IDLE state, the MME sends a 
Paging (as specified in TS 23.401 [2], and CN Domain Indicator) message to each eNodeB serving the TA list 
the UE is registered to as specified in clause 7.2. If the UE is in ECM -CONNECTED, the MME relays the CS 
Page message to the serving eNodeB over the SI interface as specified in clause 7.3. 

5b) The eNodeBs receive CS paging messages from the MME, and the procedures take place as specified in 
clause 7.2. 

6a As ISR is active and the UE is in ECM_IDLE state, the MME forwards the CS paging message received from 
the MSCA^LR to the associated SGSN. The MME gets the SGSN information in the regular ISR activation 
process. If MME received the priority marking in step4, it forwards CS paging message with priority marking, 
e.g. eMLPP priority, to the SGSN. 

6b)The SGSN receives the CS paging message from the MME, the SGSN sends paging messages to RNS/BSSs, 
which is described in detail in TS 23.060 [3]. 

The SGSN shall not implement a local retransmission scheme for the lu/Gb paging messages. 

6c) When RNS/BSS nodes receive paging message from the SGSN, paging is initiated as described in detail in 
TS 23.060 [3]. 

NOTE: If ISR is not active or the UE is in ECM-CONNECTED state, the MME does not send the CS paging 
message to the SGSN. That means, the steps of 6a, 6b, 6c are not needed in the MT call procedure. 

7) Upon receipt of a Paging Request message for a circuit-switched service, the CS Fallback (as defined in this 
specification) or Cell Reselection (as defined in TS 23.060 [3]) take place, and the UE accesses CS domain from 
UMTS/GSM. 

8) When the CS Fallback or Cell Reselection completes, the UE responds to the CS paging request and returns the 
CS paging response as described in detail in this specification and TS 23.060 [3] to the RNS/BSS. 
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9) When received at the RNS/BSS, the CS Paging Response message is sent to the MSC/VLR as described in detail 
in TS 23.060 [3]. The MSC/VLR receives CS paging response contained in corresponding message which shall 
then stop the paging response timer and establish the CS connection, then the MT call process as described in 
detail in TS 23.018 [5]. 

7.7.3 Void 

7.8 Mobile Terminating Call when SGs is not active 

Regular pre-Release 8 MSC procedures are performed without any ISR or SGs specifics. 



8 Other CS Services 

8.1 General 

The MSC handles the timers, queuing and retransmission for sending the SGsAP-P AGING-REQUEST message on the 
SGs interface in the same way that it handles the sending of a PAGING message on the A or lu interface. As a 
consequence, the MME and (if ISR is active) the SGSN shall not implement local retransmission schemes for this 
paging. 

8.2 Short Message Service (SMS) 

8.2.1 General 

The procedures for SMS in this specification apply only if the UE is EPS/IMSI attached and the Non Access Stratum 
signalling based SMS transfer is chosen by the UE and/or the home PLMN for delivering short messages. 

This clause describes both the mobile originating and mobile terminating SMS over SGs procedures in EPS. SMS 
support is based on the connectionless SGs reference point between the MME and the MSC Server and use of NAS 
signalling between the UE and the MME, i.e. no CS Fallback is performed for SMS. 

This clause also describes the SMS procedures between the UE and the MME for UEs that use only PS and SMS 
services but no CS Fallback via GERAN and/or UTRAN. 

The SMS protocol entities are reused from the existing MS/UE and MSC implementations. This means that the SMS 
over SGs procedures reuse the different protocol layers as defined in TS 23.040 [14]. 

NOTE. With SMS over SGs, the MSCA^LR produces the Call Detail Record. The stage 3 changes to the CDR for 
SMS over SGs were made in a manner that should permit an unmodified Release 7 entity to receive the 
CDR. However, for correct operation of, e.g. customer care services, when using an unmodified Release 7 
entity to receive the CDR, the VPLMN should ensure that the TAC values do not overlap with the LAC 
values. 

8.2.2 IVIobile originating SIVIS in Idle IVIode 

The following sequence flow shows the delivery of mobile originating SMS in idle mode. The message flows between 
the ME/UE and MSC/VLR are also broadly applicable to the Memory Available Notification. 
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Figure 8.2.2-1 : Mobile originating SMS in idle mode 

1. The combined EPS/IMSI attach procedure as described in clause 5.2 has been performed earher. 

2. A mobile originating SMS is triggered and the MS/UE is in idle mode. The MS/UE initiates the UE triggered 
Service Request procedure, which is defined in TS 23.401 [2]. The UE indicates its S-TMSI in the RRC 
signalling. 

3. The MS/UE builds the SMS message to be sent as defined in TS 23.040 [14] (i.e. the SMS message consists of 
CP-DATA/RP-DATA/TPDU/SMS-SUBMIT parts). Following the activation of the Radio Bearers, the SMS 
message is encapsulated in an NAS message and sent to the MME. 

4. The MME forwards the SMS message to the MSC/VLR in an Uplink Unitdata message. In order to permit the 
MSC to create an accurate charging record, the MME adds the IMEISV, the local time zone, the Mobile Station 
Classmark 2, and the UE's current TAI and E-CGI. 

4a. The MSC/VLR acknowledges receipt of the SMS to the UE. 

5.-8. These steps are performed as defined in TS 23.040 [14]. The SMS message is forwarded to the SC that 
returns a delivery report message. 

9. The MSC/VLR forwards the received delivery report to the MME associated with the MS/UE in a Downlink 
Unitdata message. 

10. The MME encapsulates the received delivery report in an NAS message and sends the message to the MS/UE. 

11. 12. The UE acknowledges receipt of the delivery report to the MSC/VLR. 

13. The MSC/VLR indicates to the MME that no more NAS messages need to be tunnelled. 

The MME should not use the SGs Release Request message as a trigger for the release of SI resources. 

NOTE: This is because the MME does not know whether the Service Request performed in step 2 was solely for 
the purpose of SMS, or, was for SMS and user plane data, or, whether or not the mobile has additional 
SMSs to send. 
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8.2.3 Mobile originating SMS in Active Mode 

Mobile Originating SMS in active Mode procedure is specified by reusing the Mobile Originating SMS in Idle Mode 
with the following modification: 

The established signalling connection between the MS/UE and the MME is reused for the transport of the SMS 
message and the delivery report (i.e. the UE triggered Service Request procedure defined in step 2 is skipped). 

8.2.3a Multiple Mobile originating SMSs 

In clause 3.2 of TS 24.01 1 [28], the simultaneous transmission of more than one MO SMS/notification per domain is 
prohibited. 

If the UE has more than one SMS/notification to send, the subsequent SMS/notification is sent at step 11 of clause 8.2.2 
and the acknowledgement of the delivery report for the previous SMS/notification is not sent. 

8.2.4 Mobile terminating SMS in idle mode 

The following sequence flow shows the delivery of mobile terminating SMS in idle mode. 
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Figure 8.2.4-1 : Mobile terminating SMS in idle mode 

1. The combined EPS/IMSI attach procedure as described in clause 5.2 has been performed. 

2-4. The SC initiates transfer of mobile terminating SMS. The HLR is requested for routing number for SMS 
services and the SMS message is forwarded to the MSC/VLR where the MS/UE is CS attached. 

5. The MSC/VLR sends a Paging (IMSI, VLR TMSI, Location Information, SMS indicator) message to the MME. 

6. The MME initiates the paging procedure by sending the Paging (as specified in TS 23.401 [2]) message to each 
eNodeB with cells belonging to the tracking area(s) in which the UE is registered. The UE is paged with its 
S-TMSI. 

7. The MS/UE is paged by the eNodeB s. 

8. The UE sends a Service Request message to the MME. The UE indicates its S-TMSI in the RRC signalling. The 
MME sends the Sl-AP Initial Context Setup Request message to the eNodeB and the eNodeB establishes the 
Radio Bearers. 
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8a. The MME sends a Service Request message to the MSC. In order to permit the MSC to create an accurate 

charging record, the MME adds the IMEISV, the local time zone, the Mobile Station Classmark 2, and the UE's 
current TAI and E-CGI. 

9a. The MSCA^LR builds the SMS message to be sent as defined in TS 23.040 [14] (i.e. the SMS message consists 
of CP-DATA/RP-DATA/TPDU/SMS-DELIVER parts). The MSC/VLR forwards the SMS message to the MME 
in a Downlink Unitdata message. 

9b. The MME encapsulates the SMS message in a NAS message and sends the message to the MS/UE. 

9c, 9d. The MS/UE acknowledges receipt of the SMS message to the MSCA^LR. 

10. The MS/UE returns a delivery report as defined in TS 23.040 [14]. The delivery report is encapsulated in an 
NAS message and sent to the MME. 

1 1 . The MME forwards the delivery report to the MSC/VLR in an Uplink Unitdata message. 

12-13. These steps are performed as defined in TS 23.040 [14]. The delivery report is forwarded to the SC. 

14-15. In parallel to steps 12-13, the MSC/VLR acknowledges receipt of the delivery report to the MS/UE. 

16. The MSC/VLR indicates to the MME that no more NAS messages need to be tunnelled. 

The MME should not use the SGs Release Request message as a trigger for the release of SI resources. 

NOTE: Although the MME could use the RRC establishment cause (set to mt- Access) sent in the Sl-AP Initial 
UE Message in step 8 to deduce that the MS/UE sent the Service Request solely for receiving the SMS), 
the MME does not know whether the MT-SMS might cause the initiation of user plane traffic or an MO 
SMS. So, for simplicity of MME implementation, the normal eNodeB procedures should be used to 
initiate the release of S 1 resources. 

8.2.5 Mobile terminating SMS in Active Mode 

Mobile terminating SMS in Active Mode procedure is specified by reusing the Mobile Terminating SMS in Idle Mode 
with the following modification: 

There is no need for the MME to perform Paging of the MS/UE after step 5. MME continues with step 8a (i.e. 
steps 6 to 8 are skipped). The MME immediately sends a Downlink Unitdata to the UE. 

- The MME also includes the E-CGI and TAI in step 9d. 

8.2.5a Multiple Mobile terminating SMSs 

In clause 3.2 of TS 24.01 1 [28], the simultaneous transmission of more than one MT SMS per domain is prohibited. 

If the MSC/VLR has more than one SMS to send, the subsequent SMS is sent in a Downlink Unitdata message after 
step 14 and instead of the Release Request in step 16 of clause 8.2.4. i.e. the MSC/VLR does not need to send another 
SGs Paging message. 

8.2.5b Simultaneous Mobile terminating and Mobile originating SMSs 

The above sections on mobile originating and mobile terminating SMS handling in active and idle mode can be reused 
such that no special treatment is needed for this case. 

8.2.5c Unsuccessful Mobile terminating SMS delivery attempt 

As specified in clause 3.2.8 of TS 23.040 [14], setting the Mobile Station Not Reachable Flag (MNRF) in the 
MSC/VLR is mandatory. However, when using the SGs interface, the MSC/VLR has delegated the 'implicit detach' 
functionality to the MME (and/or, if Network Mode of Operation 1 is in use in GERAN/UTRAN, to the SGSN). 

If an SGs based MT SMS delivery attempt fails, the MSC/VLR shall set its MNRF and send an SGs interface Alert 
Request message to the MME. Upon receipt of Alert Request message, MME shall set its Non-EPS Alert Flag (NEAF) 
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and if ISR is activated, the MME shall then send an S3 interface Alert-MME-Request message to the SGSN. SGSN 
shall set the S3 SMS Alert Flag (SSAF). 

If the MME operator knows (e.g. because it is in the HPLMN) that the receiving UE's HPLMN deploys SMS-Router, 
and if the receiving UE's HPLMN uses both SMS via MSC and SMS via SGSN, then the MME need not send the Alert- 
MME-Request message to the SGSN for that UE. 

NOTE: The receiving UE's HPLMN should ensure that the SMS-Router in the receiving UE's HPLMN only 
returns SMS-Router address to the SMS-GMSC of the sender UE's PLMN. 

Subsequently, if the UE makes radio contact with the SGSN and SSAF is set, the SGSN informs the MME with an S3 
interface UE- Activity-Indication. Upon receipt of the S3 interface UE- Activity-Indication, or, if the UE makes radio 
contact with the MME, the MME sends an SGs AP UE-Activity-Indication message to the MSC/VLR. Upon receipt of 
an SGs AP UE-Activity-Indication message, or signalling on the A, lu-cs or Gs interface for that UE, the MSC/VLR 
shall inform the HLR. 

8.2.5d Non-SMS Mobile terminating activity during SMS delivery 

While one or more SMS is being transferred, other mobile terminating requests (e.g. an MT voice call) may arrive in the 
MSCA^LR. If this happens the MSC/VLR continues the SMS activities but shall also send the SGs Paging message for 
the non-SMS activity to the MME. The MME shall handle this SGs Paging message as if no SMS transfers are ongoing. 
Typically this should lead to the MME invoking the handover/call redirection to GERAN/UTRAN features and it may 
lead to disruption of the SMS delivery. The MSC/VLR and UE shall recover from any such SMS disruption using the 
normal RP and CP layer retransmission timers/mechanisms. 

8.2.5e Non-SMS Mobile originating activity during SMS delivery 

While one or more SMS is being transferred, other mobile originating requests (e.g. an MO voice call or USSD) may be 
requested by the user. If this happens the MS/UE continues the SMS activities but shall also send the Extended Service 
Request message for the non-SMS activity to the MME. The MME shall handle this Extended Service Request message 
as if no SMS transfers are ongoing. Typically this should lead to the MME invoking the handover/call redirection to 
GERAN/UTRAN features and it may lead to disruption of the SMS delivery. The MSC/VLR and UE shall recover from 
any such SMS disruption using the normal RP and CP layer retransmission timers/mechanisms. 

8.2.5f Mobile Terminating SMS when ISR is active and SGs is active 
between MSC/VLR and MME 

When the MME receives the SGs Paging message for SMS, and ISR is active, and the UE is in idle mode, the MME 
sends the SI interface paging message to the E-UTRAN (using the S-TMSI as temporary identity) and sends a CS 
paging message (SMS indicator) to the SGSN using the MSC TMSI as temporary identity (unless the MSC did not 
allocate a TMSI, in which case the IMSI is used for paging). 

The UE is paged on E-UTRAN and by the SGSN on GERAN and/or UTRAN. For GERAN A/Gb mode, the SGSN 
sends a PAGING CS message to the BSS (see TS 48.018 [30]). For UTRAN, the SGSN sends a PAGING message to 
the UTRAN (see TS 25.413 [29]) with the CN Domain Indicator set to 'CS domain' and the Paging Cause set to 
'Terminating Low Priority Signalling'. The UE responds on the cell on which it is camped. When camped on E- 
UTRAN, the UE responds to the MME. When camped on GERAN or UTRAN, the UE responds to the MSC. 

8.2.6 Co-Existence with SMS over generic 3GPP IP access 

If the home operator has deployed SMS over generic 3GPP IP access and/or SMS-Instant Messaging Interworking as 
defined in TS 23.204 [15], and has configured the network and the UE for using SMS over IP or SMS-Instant 
Messaging Interworking, then an SMS or IM will be delivered over EPS in any visited network whether or not the 
visited network supports SMS over generic 3GPP IP access. 

If the home operator has not deployed SMS over generic 3GPP IP access and the UE fails to successfully complete the 
combined EPS/IMSI attach procedure in the visited network (i.e. the visited network supports SMS over generic 3GPP 
IP access and does not support SGs for SMS capability), then the UE cannot execute MT or MO SMS procedures in the 
visited network. 
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8.3 Location Services (LCS) 
8.3.1 IVIO-LR procedure 
8.3.1.1 General 

MO-LR procedure in the CS fallback in EPS is performed as specified in TS 23.271 [8]. 

When the MO-LR procedure is triggered by the UE's application, UE will check the LCS Support Indication provided 
by the Attach and TAU procedures as specified in TS 23.401 [2]: 

- If the LCS Support Indication indicates EPC -MO-LR is supported, and if the UE supports EPC-MO-LR, the UE 
stays in LTE and initiates the EPC-MO-LR procedure. 

If EPC-MO-LR is not supported by either the network or the UE and if the LCS Support Indication indicates CS- 
MO-LR is supported, and the UE supports CS-MO-LR, the UE assumes CS-MO-LR is provided. Also, if EPC- 
MO-LR is not supported by either the network or the UE and if network does not provide information on 
whether CS-MO-LR is supported, then UE assumes CS-MO-LR may be provided. In these cases, if the previous 
combined EPS/IMSI Attach or Combined TA/LA Update is accepted with no "SMS only" indication, then the 
UE initiates CS Fallback to perform CS-MO-LR. 

NOTE: Based on UE implementation, UE may avoid initiating CS-MO-LR when an IMS VoIP session is active. 

- Otherwise, the UE shall not attempt the EPC-MO-LR procedure, i.e. neither EPC-MO-LR nor CS-MO-LR with 
CS Fallback. 

If the UE decided to initiate the CS Fallback for the LCS based on LCS Support Indication check, then, the following 
applies: 

When the UE is in active mode without an IMS VoIP session, the UE and the network follow the procedure in 
clause 6.2 "Mobile Originating Call in Active Mode - PS HO supported" or clause 6.3 "Mobile Originating call 
in Active Mode - No PS HO supported". After the UE changes its RAT from E-UTRAN to UTRAN/GERAN, it 
performs CS-MO-LR procedures as specified in TS 23.271 [8]. 

When the UE is in active mode with an IMS VoIP session and if the UE supports SRVCC procedures, the UE 
and the network follow the procedure in clause 8.3.1.2 "MO-LR in Active Mode with IMS VoIP session - PS 
HO supported". 

When the UE is in active mode without an IMS VoIP session but the network decides not to perform PS- 
Handover, then the UE and the network follow the procedure in clause 6.3 "Mobile Originating Call in Active 
Mode - No PS HO Support". After the UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs 
CS-MO-LR procedure as specified in TS 23.271 [8]. 

When the UE is in active mode with an IMS VoIP session and if the UE supports SRVCC procedures but the 
network decides not to perform PS-Handover, then the UE and the network follow the procedure in 
clause 8.3.1.3 "MO-LR in Active Mode with IMS VoIP session - No PS HO supported". 

When UE is in idle mode, UE follows the procedure in clause 6.4 "Mobile Originating Call in Idle Mode". After 
UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs CS-MO-LR procedure as specified in 
TS 23.271 [8]. 
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8.3.1 .2 MO-LR in Active Mode with IMS VoIP session - PS HO supported 
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Figure 8.3.1 .2-1 : MO-LR Request in E-UTRAN while UE is in IMS VoIP session 

la. -2. These steps are performed as defined in clause 6.2. 

3. Based on UE measurement reports and CS Fallback Indicator in step lb, the source E-UTRAN decides to trigger 
an SRVCC handover to UTRAN/GERAN. Continuous SRVCC procedures are continued as specified in 

TS 23.216 [20], clause 6.2.2.2. 

4. After sending a Handover Complete message via the RNS/BSS to the MSC in step 3, the UE sends a CM Service 
Request to the MSC indicating a request for location services. After the HLR is updated and the subscriber data 
are downloaded from the HLR, the MSC sends a CM Service Accept to the UE. Then the UE sends a NAS MO- 
LR Request to the MSC. 

5. Continuation of MO-LR procedures as specified in TS 23.271 [8], clause 9.2.6. 

NOTE: When SRVCC capable UE is in active mode with an IMS VoIP session but the network does not support 
SRVCC, MME sends Extended Service Reject in response to step la based on EPS bearer information, 
i.e. MME rejects the request if UE has EPS bearer with QC1=1, i.e. IMS VoIP session. 



8.3.1.3 



MO-LR in Active Mode with IMS VoIP session - No PS HO supported 



The same procedure as described in clause 8.3.1.2 applies for "MO-LR in Active Mode with IMS VoIP session - No PS 
HO supported" case except that the SRVCC procedure in step 3 follows TS 23.216 [20], clause 6.2.2.1a. 
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8.3.2 MT-LR procedure 

8.3.2.1 MT-LR procedure if UE is not in IMS VoIP session 
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Figure 8.3.2.1-1 : MT-LR procedure if UE is not in IIVIS VoIP session 

1. MSC receives a PROVIDE_SUBSCRIBER_LOCATION message due to CS-MT-LR (TS 23.271 [8], 
clause 9.1.2). 

2. MSC sends Paging (LCS Client Identity, LCS indicator) message to MME. 

3. If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator, LCS Client 
Identity, LCS indicator) message to UE. LCS indicator is used to inform the UE that this paging if for MT-LR 
request. LCS Client Identity and LCS indicator are only included in CS Page if UE is in active mode. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send Paging to the UE, and the MME sends CS Paging Reject towards MSC to 
stop CS Paging procedure and this CSFB procedure stops. 

4. UE responds with Paging_Resp message in UMTS/GERAN. Service based redirection/reselection or PS 
Handover may take place as specified in clause 7. 

5. MSC continues with the CS-MT-LR procedure as defined in TS 23.271 [8], clause 9.1.2. 



£75/ 



3GPP TS 23.272 version 11.5.0 Release 11 



59 



ETSI TS 123 272 V1 1.5.0 (2013-06) 



8.3.2.2 



MT-LR procedure while UE is in IMS VoIP session 
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Figure 8.3.2.2-1 : MT-LR procedure while UE is in IMS VoIP session 

1. MSC receives a PROVIDE_SUBSCRIBER_LOCATION message due to CS MX LR (TS 23.271 [8], 
clause 9.1.2). 

la. The MSC responds by sending a Paging Request (LCS Client Identity, LCS indicator) to the MME over a SGs 
interface. The MSC only sends a CS Page for an UE that provides location update information using the SGs 
interface. The MME has an established S 1 connection for IMS VoIP session. 

If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator, LCS Client 
Identity, LCS indicator) message to UE. LCS indicator is used to inform the UE that this paging is for MT-LR 
request. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send Paging to the UE, and the MME sends CS Paging Reject towards MSC to 
stop CS Paging procedure and this CSFB procedure stops. 

The eNodeB forwards the paging message to the UE. 

lb. UE sends an Extended Service Request (Reject or Accept) message to the MME for mobile terminating CS 
Fallback. The Extended Service Request message is encapsulated in RRC and Sl-AP messages. The UE may 
decide to reject CSFB based on LCS Client Identity. 

Ic. Upon receiving the Extended Service Request (Reject) for mobile terminating CS Fallback, the MME sends 
Paging Reject towards MSC to stop CS Paging procedure and this CSFB procedure stops. Corresponding error 
handling is returned to the GMLC as specified in TS 23.271 [8]. 

Id. MME sends an Sl-AP Request message to eNodeB that includes the UE Radio Capabilities and a CS Fallback 
Indicator. This message: indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. 

le. The eNodeB shall reply with Sl-AP Response message. 

2. These steps are performed as defined in clause 7.3 for PS handover supported case and clause 7.4 for No PS 
handover supported case. 

3. Based on UE measurement reports and CS Fallback Indicator in step Id, the source E-UTRAN decides to trigger 
an SRVCC handover to UTRAN/GERAN. Continuous SRVCC procedures as specified in TS 23.216 [20], 
clause 6.2.2.2 for PS handover supported case and clause 6.2.2.1a for No PS HO supported case are performed. 
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4. After receiving Relocation/Handover Complete message from the RNS/BSS in step 3, MSC sends LCS Location 
Notification Invoke to the UE. 

5. Continuation of CS-MT-LR procedures as specified in TS 23.271 [8], clause 9.1.2. 

NOTE: When SRVCC capable UE is in active mode with an IMS VoIP session but the network does not support 
SRVCC, MME sends Paging Reject towards MSC and this CSFB procedure stops. This is based on the 
bearer information at MME indicating UE has IMS VoIP session, i.e. EPS bearer with 
QCI= 1 .Corresponding error handling is returned to the GMLC as specified in TS 23.271 [8]. 

8.3.3 NI-LR procedure 

NI-LR procedure takes place during emergency calls, and is thus performed in GERAN/UTRAN during the Mobile 
Originating call procedure. 

8.3.4 Returning back to E-UTRAN 

Once CS service ends in CS domain, existing mechanisms as specified in TS 23.401 [2] can be used to move the UE to 
E-UTRAN, no specific CS Fallback mechanisms are needed. 

During the release of an RR connection the MSC should indicate to GERAN/UTRAN that the RR connection (for call 
or CISS or LCS) was established as a result of CS fallback. GERAN and UTRAN may use the indication to determine 
which of the existing mechanisms that should be used to move the UE to E-UTRAN. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC shall 
further indicate to GERAN/UTRAN the last used LTE PLMN ID. GERAN and UTRAN shall take the last used LTE 
PLMN ID into account when selecting the target cell in PS handover to E-UTRAN or the dedicated target frequency list 
for idle mode mobility to E-UTRAN in RR Connection Release procedure. 

8.3.5 Co-Existence witin Otiner Location Services 
8.3.5.1 Co-Existence with SUPL 

There is no race condition between OMA AD SUPL [9] and CS Fallback for LCS. When network initiated SUPL 
procedure takes place, the paging message does not contain CN Domain Indicator by default. This prevents CS Fallback 
for LCS to take place. For SET initiated SUPL procedure, changing of RAT does not take place. 

8.4 Other CS Services 

8.4.0 General 

The procedures specified in this clause apply when the UE is EPS/IMSI attached and the CS domain is chosen by the 
UE and/or the home PLMN to deliver other types of CS services, i.e. services not covered explicitly in previous 
sections, such as Call Independent Supplementary Services, real time end-to-end facsimile group 3 services, 
TS 23.146 [41], etc. 

8.4.1 Mobile-Initiated CS Services 

8.4.1 .1 Mobile-Initiated CS Services if UE is not In IMS VoIP session 

When UE is in active mode, UE and the network follow the procedure in clause 6.2 "Mobile Originating Call in 
Active-Mode". After UE changes its RAT from E-UTRAN to UTRAN/GERAN, it performs Mobile-Initiated CS 
procedures relevant to the initiated CS service, e.g. Call Independent Supplementary Service procedure as specified in 
TS 24.010 [13], real time end-to-end facsimile group 3 procedure as specified in TS 23.146 [41], etc. 

When UE is in active mode and network initiates NACC procedure, then UE and the network follow the procedure in 
clause 6.3 "Mobile Originating Call in Active Mode - No PS HO Support in GERAN". After UE changes its RAT from 
E-UTRAN to UTRAN/GERAN, it performs Mobile-Initiated CS procedures relevant to the initiated CS service, e.g. 
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Supplementary Service procedure as specified in TS 24.010 [13], real time end-to-end facsimile group 3 procedure as 
specified in TS 23.146 [41], etc. 

When UE is in idle mode, UE and the network follows the procedure in clause 6.4. After UE changes its RAT from 
E-UTRAN to UTRAN/GERAN, it performs Mobile-Initiated CS procedures relevant to the initiated CS service, e.g. 
Supplementary Services procedure as specified in specifications such as TS 23.090 [10], real time end-to-end facsimile 
group 3 procedure as specified in TS 23.146 [41], etc. 



8.4.1.2 



Mobile-Initiated CS Services while UE is in IMS VoIP session 



When the UE is in active mode with an IMS VoIP session and if the UE supports SRVCC procedures, the procedure for 
Mobile-Initiated CS Services while UE is in IMS VoIP session is the same as for "NW-Initiated CS Services while UE 
is in IMS VoIP session" in clause 8.4.2.2 from step lb (Extended Service Request), with the difference that the 
Extended Service Request is for mobile originating CS Fallback. 

8.4.2 NW-Initiated CS Services 
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Figure 8.4.2.1-1 : NW-Initiated CS Service procedure 

1 . MSC/VLR receives a trigger for a NW-Initiated CS procedure. 

2. MSC/VLR sends Paging message to MME. For call independent supplementary service, the Paging message 
may include the SS service ID. 

3. If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator) message to 
UE. For call independent supplementary service the Paging message may include the SS service ID. SS service 
ID is used to indicate the type of the supplementary service (e.g. USSD) to the UE. The SS service ID is only 
included in CS Page if UE is in active mode. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the Paging to the UE, and the MME sends CS Paging Reject towards MSC 
to stop CS Paging procedure and this CSFB procedure stops. 

4. The mobile terminating call procedure then takes place as specified in clause 7 "Mobile Terminating Call 
Procedure". 

5. Once the paging is successfully returned to MSC, the applicable CS procedures continues, e.g. for 
Supplementary Service as specified in specifications such as TS 23.090 [10]. 
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8.4.2.2 



NW-lnitiated CS Services while UE is in IIVIS VoIP session 
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Figure 8.4.2.2-1 : NW-lnitiated CS Service procedure while UE is in IMS VoIP session 

1 . MSC/VLR receives a trigger for a NW-lnitiated CS procedure. 

la. The MSC responds by sending a Paging Request to the MME over a SGs interface. For call independent 
supplementary service, the Paging message may include the SS service ID. The MME has an established SI 
connection for IMS VoIP session. 

If the MME did not return the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME sends Paging (parameters as specified in TS 23.401 [2], CN Domain Indicator) message to 
UE. For call independent supplementary service the Paging message may include the SS service ID. SS service 
ID is used to indicate the type of the supplementary service to the UE. The SS service ID is only included in CS 
Page if UE is in active mode. 

If the MME returned the "SMS-only" indication to the UE during Attach or Combined TA/LA Update 
procedures, the MME shall not send the Paging to the UE, and the MME sends CS Paging Reject towards MSC 
to stop CS Paging procedure and this CSFB procedure stops. 

The eNodeB forwards the paging message to the UE. 

lb. UE sends an Extended Service Request (Reject or Accept) message to the MME for mobile terminating CS 
Fallback. The Extended Service Request message is encapsulated in RRC and Sl-AP messages. 

Ic. Upon receiving the Extended Service Request (Reject) for mobile terminating CS Fallback, the MME sends 
Paging Reject towards MSC to stop CS Paging procedure and this CSFB procedure stops. Corresponding error 
handling is returned to the GMLC as specified in TS 23.271 [8]. 

Id. MME sends an Sl-AP Request message to eNodeB that includes the UE Radio Capabilities and a CS Fallback 
Indicator. This message indicates to the eNodeB that the UE should be moved to UTRAN/GERAN. 

le. The eNodeB shall reply with Sl-AP Response message. 

2. These steps are performed as defined in clause 7.3 for PS handover supported case and clause 7.4 for No PS 
handover supported case. 

3. Based on UE measurement reports and CS Fallback Indicator in step Id, the source E-UTRAN decides to trigger 
an SRVCC handover to UTRAN/GERAN. Continuous SRVCC procedures as specified in TS 23.216 [20], 
clause 6.2.2.2 for PS handover supported case and clause 6.2.2.1a for No PS HO supported case are performed. 
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4. After receiving Relocation/Handover Complete message from the RNS/BSS in step 3, the applicable CS 
procedure continues, e.g. for Supplementary Service as specified in specifications such as TS 23.090 [10]. 

NOTE: When SRVCC capable UE is in active mode with an IMS VoIP session but the network does not support 
SRVCC, MME sends Paging Reject towards MSC and this CSFB procedure stops. This is based on the 
bearer information at MME indicating UE has IMS VoIP session, i.e. EPS bearer with QCI=1. 

8.4.3 Returning back to E-UTRAN 

Once CS service ends in CS domain, existing mechanisms as specified in TS 23.401 [2] can be used to move the UE to 
E-UTRAN, no specific CS Fallback mechanisms are needed. 

During the release of an RR connection the MSC should indicate to GERAN/UTRAN that the RR connection (for call 
or CISS or LCS) was established as a result of CS fallback. GERAN and UTRAN may use the indication to determine 
which of the existing mechanisms that should be used to move the UE to E-UTRAN. 

Dependent on configuration and the CS service is due to CSFB, during the release of an RR connection the MSC shall 
further indicate to GERAN/UTRAN the last used LTE PLMN ID and UTRAN shall take the last used LTE PLMN ID 
into account when selecting the target cell in PS handover to E-UTRAN or the target frequency list for idle mode 
mobility to E-UTRAN in RR Connection Release procedure. 
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Annex A: 
Void 
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Annex B (normative): 
CS Fallback to 1xRTT 



This annex describes a CS Fallback to IxRTT and an SMS solution for dual mode IxRTT/E-UTRAN terminals. 

CS Fallback to IxRTT is supported for UEs with both single Rx and dual Rx configuration (see TS 36.331 [33]). UEs 
with single Rx configuration are not able to camp in IxRTT when they are active in E-UTRAN. The network therefore 
provides mechanisms for the UE to perform registration to IxRTT, receive IxRTT paging, SMS etc. while the UE is in 
E-UTRAN. UEs with dual Rx configuration can camp in IxRTT while they are active in E-UTRAN, they may however 
not be able to stay in E-UTRAN when they handle a CS call and/or perform registration signalling, and/or sending or 
receiving SMS in IxRTT. 

Clause B.l and B.2 describes the architecture and procedures for CS Fallback (and enhanced CS Fallback) to IxRTT 
when the UE has single Rx, dual Rx, or dual Rx/Tx configuration. In this scenario the network need to support the SI 02 
interface between the MME and IxCS system in order to support CS Fallback (this is indicated by the presence of 
CSFB registration parameters on E-UTRAN broadcast channel, TS 36.331 [33]). 

Clause B.3 describes the procedures for CS Fallback when the UE has dual Rx configuration. In this scenario the 
network needs to support the Extended Service Request procedure in order to support CS Fallback (this is indicated by 
either the presence of CSFB registration parameters or indication of support for dual rx CSFB on E-UTRAN broadcast 
channel, TS 36.331 [33]). 

If the UE has a dual Rx configuration and indicates support for enhanced CS fallback to IxRTT in the UE radio 
capabilities, the principles and procedures in clauses B.l and B.2 are followed when the network indicates support for 
S102. 



B.1 Overall Description 
B.1.1 General Considerations 

The CS fallback for IxRTT in EPS enables the delivery of CS-domain services (e.g. CS voice) by reuse of the IxCS 
infrastructure when the UE is served by E-UTRAN. A CS fallback enabled terminal, while connected to E-UTRAN 
may register in the Ix RTT CS domain in order to be able to use IxRTT access to establish one or more CS services in 
the CS domain. The CS Fallback function is only available where E-UTRAN coverage overlaps with IxRTT coverage. 

This specification also specifies the architecture required for SMS over SI 02 in EPS. The MO SMS and MT SMS are 
tunnelled in EPS and over SI 02 and do not cause any CS Fallback to CDMA IxRTT, and consequently does not require 
any overlapped CDMA IxRTT coverage. 

CS Fallback to IxRTT and IMS-based services shall be able to co-exist in the same operator's network. 

CS Fallback to IxRTT with PS Handover procedure to HRPD access for Optimised HO, non-Optimised HO, and 
Optimised Idle mode mobility as defined in TS 23.402 [27] shall be able to co-exist in the same operator's network. 

B.1 .2 Reference Architecture 

The CS fallback to IxRTT and SMS over S102 in EPS function is realised by reusing the S102 reference point between 
the MME and the IxCS IWS. The reference architecture described in figure B.l. 2-1 is similar to the SRVCC 
architecture for E-UTRAN to 3GPP2 IxCS described in TS 23.216 [20], with the additional aspect that the S102 
session is long-lived (similar to pre-registration for SlOl). 
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Figure B. 1.2-1 : Reference architecture for CS fallbacl< to IxRTT CS 

Reference architecture for PS handover procedure between E-UTRAN and HRPD access is defined in TS 23.402 [27]. 

B. 1 .2. 1 Reference points 

S102: It is the reference point between the MME and the IxCS IWS. The S102 reference point provides a tunnel 
between MME and 3GPP2 IxCS IWS to relay 3GPP2 IxCS signalling messages. Ix CS signalHng 
messages are those messages that are defined for A21 interface as described in 3GPP2 A.S0008-C [16] 
and3GPP2A.S0009[17]. 

B.1.3 Functional entities 
B.1.3.1 UE 

The UE capable of CS fallback to IxRTT and SMS over S102 supports access to E-UTRAN/EPC as well as access to 
the IxCS domain over IxRTT. It supports the following additional functions: 

IxRTT CS registration over the EPS after the UE has completed the E-UTRAN attachment; 

IxRTT CS re-registration due to mobility; 

CS fallback procedures specified for IxRTT CS domain voice service; 

Procedures for mobile originated and mobile terminated SMS tunnelled over EPS and S102; 

Includes enhanced CS fallback to IxRTT capability indication as part of the UE radio capabilities; 

Includes concurrent 1 xRTT and HRPD capability indication as part of the UE radio capabilities if supported by 
the enhanced CS fallback to IxRTT capable UE. 

If the UE is service user with subscription to CS domain priority service, the UE's USIM belongs to one of the special 
Access Classes as specified in TS 22.01 1 [38] and the UE shall set the RRC establishment cause to 
"HighPriority Access" as specified in TS 36.331 [33]. 

B.1.3.2 IVIIVIE 

The MME enabled for CS fallback to IxRTT supports the following additional functions: 
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It serves as a signalling tunnelling end point towards the 3GPP2 IxCS IWS via S 102 interface for 
sending/receiving encapsulated 3GPP2 IxCS signalling messages to/from the UE, which are encapsulated in Sl- 
MME SI Information Transfer messages, as defined in TR 36.938 [19]; 

IxCS-IWS (terminating S102 reference point) selection for CSFB procedures; 

Handling of S 102 tunnel redirection in case of MME relocation; 

Buffering of messages received via S 102 for UEs in idle state. 

If the network supports CSFB priority call handling, the MME supports the following additional functions: 

For page message received on the SI 02 interface with priority indication, the MME provides preferential 
treatment to this message and also the subsequent CS fallback procedure compared to other normal transactions. 
If UE needs to be paged, the MME sets priority indication on the paging request to eNodeB. The MME also sets 
priority indication, i.e. "CSFB High Priority", in SlAP message to the eNodeB, so that eNodeB may initiate the 
CSFB procedure with priority, as specified in TS 36.413 [35]. 

For a CSFB request from service user, the MME determines that the CSFB request need priority handling based 
on the UE's EPS subscription information. The MME in congestion situation provides preferential treatment to 
this request and also sets priority indication, i.e. "CSFB High Priority", in SlAP message to eNodeB to initiate 
CSFB procedure, as specified in TS 36.413 [35]. 

B.1.3.3 E-UTRAN 

The E-UTRAN enabled for CS fallback to IxRTT supports the following additional functions: 

Provision of control information that causes the UE to trigger IxCS registration; 

Forwarding Ix RTT CS paging request to the UE; 

Forwarding Ix RTT CS related messages between MME and UE; 

Release of E-UTRAN resources after UE leaves E-UTRAN coverage subsequent to a page for CS fallback to 
IxRTT CS if PS handover procedure is not performed in conjunction with IxCS fallback; 

Invoking the optimised or non-optimised PS handover procedure concurrently with enhanced IxCS fallback 
procedure when supported by the network and UE, and based on network configuration. 

If the network supports CSFB priority call handling, the E-UTRAN supports the following additional functions: 

For page message received on SlAP with priority indication, the E-UTRAN should provide preferential 
treatment to this request compared to other normal paging requests. 

For CS fallback SlAP message with priority indication and if the UE is idle, the E-UTRAN should provide 
preferential treatment in allocating E-UTRAN radio bearer resources compared to other normal resource 
requests. Also, E-UTRAN shall not trigger enhanced IxCSFB with concurrent optimized PS handover to HRPD 

access. 

B.1 .4 Co-existence with IIVIS services 

Clause 4.4 of this specification also applies here. 



B.1 .5 CSFB Priority Call Handling 



Priority call handling support for CSFB ensures that end-to-end priority handling is provided for both mobile originated 
CSFB calls by a service user in E-UTRAN and for mobile terminated CSFB call from a service user to a normal or 
service user in E-UTRAN. A service user's EPS subscription information contains an indication of the users IxRTT CS 
domain priority status, i.e. a MPS CS priority. If the UE is subscribed to CS domain priority, the UE's USIM shall 
belong to one of special Access Classes as specified in TS 22.01 1 [38]. 

For mobile terminated CS fallback calls from a service user, the Ix MSC via the IxCS IWS provides a priority 
indication to the MME along with a page message. The MME shall set a priority indication to the eNodeB when 
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requesting the eNodeB to page the UE if the UE is idle. For mobile originated CS fallback calls from a service user in 
E-UTRAN, the MME determines that the CSFB requires priority handling based on the MPS CS priority in the UE's 
EPS subscription. For both mobile originated and mobile terminated CSFB, the MME shall also provide priority 
indication, i.e. "CSFB High Priority", when requesting the eNodeB to execute the CSFB priority procedure. The 
eNodeB should handle the page message with priority and also prioritize the subsequent CS fallback procedure to 
IxRTT as specified in TS 36.413 [35]. 



B.2 Procedures 



B.2.1 Mobility Management 

B.2.1 .1 1x RTT CS Pre-Registration over EPS Procedure 

This clause describes how the UE in an E-UTRAN system establishes and maintains pre -registration in the IxCS 

system. 




E- 
UTRAN 




1. UE attaches to E-UTRAN as specified in TS 23.401 



2. Decision to 

register with 

IxRTT CS 



ZT 



3. Service Request procedure if the UE is in idle state. 



4. IxRTT 

-► 



4a. UUDL Information 
Transfer 



6. IxRTT CS registration response 



6c. UUDL Information 
Transfer 



CS registration request 



4b. UL/DL S1 cdma2000 
Tunnelling 



6b UL/DL SI cdma2000 
Tunnelling 



4c. S102 Direct Transler 




5. Location update to IxRTT CS domain 



6a. S102 Direct Transler 



Figure B.2. 1.1-1: IxRTT CS registration procedure 

1. The UE attaches to E-UTRAN as specified in TS 23.401 [2]. The UE includes an indication of enhanced CS 
fallback to IxRTT and may also include concurrent IxRTT and HRPD PS session handling capabilities as part 
of the UE radio capabilities. 

If the UE is a service user with subscription to Ix priority service in the IxRTT CS domain, the UE's EPS 
subscription contains MPS CS priority. 

2. Based on a radio layer trigger (e.g. an indication from the E-UTRAN when the UE is in connected state or an 
indication over the broadcast channel), the UE decides to register with the IxRTT CS domain. 
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3. If the UE is in idle state, in order to create a signalling connection with the MME, it performs the Service 
Request procedure. 

4. The UE generates a IxRTT CS registration request. 

4a. The IxRTT CS message is transferred from the UE to E-UTRAN. 

4b. E-UTRAN forwards the IxRTT CS message to the MME including the CDMA2000 Reference Cell ID. 

4c. The MME selects a IxCS IWS node based on the CDMA2000 Reference Cell ID. The IMSI is used to 

distinguish S102 signalling transactions belonging to different UEs. The MME sends a S102 Direct Transfer 
message (IMSI, IxCS message) to the IxCS IWS node. 

5. IxRTT CS registration is then performed by the IxCS IWS node based on 3GPP2 A.S0008 [16]. 

6a. IxRTT CS registration response is tunnelled back to the MME in a S 102 Direct Transfer message (IMSI, IxCS 
message). 

6b. The MME forwards the IxRTT CS message to the E-UTRAN. 

6c. The E-UTRAN forwards the IxRTT CS message to the UE. 

If the triggers for IxCS registration change over time, the UE (both in idle or connected state), uses this information to 
update the IxCS registration via the tunnel. 

B.2.1 .2 S1 02 Tunnel Redirection 

SI 02 Tunnel Redirection Procedure is used when the UE perform Tracking Area Update with MME change while the 
UE is registered with the IxRTT CS domain as described in clause B.2.1.1 and the S102 session exists between the 
MME and the IxCS IWS. 

The detail procedure for the idle case is depicted as figure B.2.1. 2-1. 
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Figure B.2.1 .2-1: S102 tunnel redirection during TAU with MME change 

1. UE performs Ix-registration over the source MME while in ECM-CONNECTED state, followed by transition to 
ECM-IDLE state. The S102 tunnel exists between the source MME and the IxCS IWS. 

2. TAU procedure with MME change as described in TS 23.401 [2], figure 5.3.3.1-1, up to and including the step 
where the target MME receives Update Location Ack from the HSS, is executed. The IxCS IWS ID is 
transferred to the target MME via the Context Response message. 

3. The target MME sends S102 Redirection Command message to the IxCS IWS. After receiving this message, the 
IxCS IWS associates the SI 02 tunnel for this specific UE with the target MME. Then the IxCS IWS releases 
any context associated with the source MME. 

4. In response to the S102 Redirection Command message, the IxCS IWS sends a S102 Redirection Ack message 
to the target MME. 
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5. The TAU procedure is completed. 
The detailed procedure for the active case is depicted as figure B. 2. 1.2-2. 
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Figure B.2. 1.2-2: S102 tunnel redirection during inter-eNodeB handover with MME relocation 

1. UE performs Ix-registration over the source MME while in ECM-CONNECTED state. The S102 tunnel exists 
between the source MME and the IxCS IWS. 

2. Inter-eNodeB handover with MME relocation procedure as described in TS 23.401 [2], figure 5.5.1.2.2-1, steps 
prior to TAU, is executed. The IxCS IWS ID is transferred to the target MME via the Forward Relocation 
Request message. 

3. The target MME sends S102 Redirection Command message to the IxCS IWS. After receiving this message, the 
IxCS IWS associates the S102 tunnel with the target MME. Then the IxCS IWS releases any context associated 
with the source MME. 

4. In response to the S102 Redirection Command message, the IxCS IWS sends a S102 Redirection Ack message 
to the target MME. 

5. The TAU procedure occurs. 

B.2.1 .3 UE-initiated Detach Procedure 

If a IxRTT CS Fallback UE, pre-registered to the IxRTT CS system, initiates the detach procedure in E-UTRAN access 
due to switch off and the UE is required to perform a "power-down registration" in the IxRTT CS system (see 
C.S0005-A [32]), the UE shall first perform the "power-down registration" procedure with the IxRTT CS system via 
the SI 02 tunnel, before initiating the detach procedure in E-UTRAN access as specified in TS 23.401 [2]. 

A IxCSF UE, pre-registered to the IxCS system, performing detach due to reasons other than switch off is not required 
to perform "power-down registration" with the IxCS system prior to performing the detach procedure in E-UTRAN. 

B.2.2 Mobile Originating Call in Active IVIode 

This clause describes the mobile originating call procedures for the CS Fallback to IxRTT in the normal case. For 
enhanced CS fallback to IxRTT procedure, see clause B.2.3a. Clause B.2.3b describes the procedure when the 
procedure is rejected by the MME. 
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Figure B.2.2-1 : CS MO call using fallback to CDMA 1x RTT network 

1. UE is E-UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1. 

2. UE makes a decision to perform a mobile originated CS call. 

3. UE sends an Extended Service Request for mobile originating IxCS fallback to the MME. 

4. MME sends UE Context Modification Request (CS Fallback Indicator, priority indicator) to E-UTRAN. CS 
Fallback Indicator indicates to the E-UTRAN to move the UE to IxRTT. 

If MME determines the CS Fallback procedure needs priority handling based on the MPS CS priority in the UE's 
EPS subscription, it sets priority indication in the SlAP message to the E-UTRAN. E-UTRAN responds with UE 
Context Modification Response 

5. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

6a. The E-UTRAN triggers RRC connection release with redirection to IxCS and continue with step 7. 

7. E-UTRAN sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates that the SI 
UE Context Release was caused by CS fallback to IxRTT. 

In case the Cause indicates that RRC was released due to abnormal conditions, e.g. radio link failure, the MME 
should continue with steps 8 -10. 

8. The MME deactivates GBR bearers towards S-GW and P-GW(s) by initiating MME-initiated Dedicated Bearer 
Deactivation procedure as specified in TS 23.401 [2], and starts the preservation and suspension of non-GBR 
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bearers by sending Suspend Notification message to the S-GW. The S-GW releases all eNodeB related 
information (address and TEIDs) for the UE, and sends Suspend Notification message to the P-GW(s). 

9. S-GW and P-GW(s) acknowledges the bearer updates by responding with Suspend Acknowledge. The MME 
stores in the UE context that UE is in suspended status. All the preserved non-GBR bearers are marked as 
suspended status in S-GW and P-GW. The P-GW discards downlink data if the UE is marked as suspended. 

10. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

11. UE moves to IxRTT and performs the procedure for mobile originating call as specified in 
3GPP2A.S0013[18]. 

Once CS service ends in the IxCS domain, the UE returns to E-UTRAN by performing reselection. The EPS service is 
resumed as described in clause 6.5. 

B.2.2a Mobile Originating call in Idle Mode 

Mobile Originating call in Idle Mode procedure is specified by reusing the Mobile Originating Call in Active mode 
procedure with Extended Service Request for mobile originating IxCS fallback to the MME where the messages Sl-AP 
UE context Modification Request and Response are replaced by Sl-AP Initial UE Context Request and Response. UE is 
transited to ECM -CONNECTED mode by following the applicable procedures specified in TS 23.401 [2]. 

If UE has only LIPA PDN connection and the cell accessed by the UE does not link to the L-GW where the UE had the 
LIPA PDN Connection, the MME shall reject the Extended Service Request with a reason code which results in the UE 
selecting IxRTT access as specified in TS 24.301 [34]. 

If the UE is a service user with subscription to CS domain priority service, the UE's USIM shall belong to one of special 
Access Classes as specified in TS 22.011 [38] and sets the RRC establishment cause to "HighPriority Access" as 
specified in TS 36.331 [33]. If the network supports a priority call handling, the MME determines that the Extended 
Service Request requires priority handling of CS Fallback based on the "HighPriority Access" establishment cause 
forwarded by eNodeB to the MME and/or MPS CS priority in the UE's EPS subscription. According to operator policy, 
the MME may use MPS CS priority to verify the priority handling of the CS Fallback procedure. 

If MME decides to perform CS Fallback with priority, it sets priority indication in the Sl-AP Initial UE Context 
Request message to the eNodeB. The eNodeB should allocate radio bearer resources to the UE preferentially compared 
to other normal calls. 



B.2.3 Mobile Terminating Call 



This clause describes the mobile terminating call procedures when the UE accepts or rejects CS paging for the CS 
Fallback to IxRTT, in the normal case. Clause B.2.3b describes the procedure when the procedure is rejected by the 
MME. 

When the Ix MSC receives a registration from a UE, it makes note of the RAN equipment from which it received the 
registration. Subsequent paging activities may thus be directed toward that RAN equipment. However, paging activities 
by the IxMSC are not limited to the single RAN equipment from which the registration was received. The MSC may 
choose to page a wider area, including inter-system paging. If the IxMSC has direct interfaces to IxCS IWS, as well as 
to IxRTT access, the MSC may choose to do direct paging activities to both E-UTRAN and Ix RAN equipments in its 
attempts to contact the UE. 

The Ix paging request sent by the IxMSC to the IxCS IWS is delivered to the UE via the tunnel. The UE tunes to 
IxRTT access, acknowledges the Ix page and performs the IxCS procedures for mobile terminated call. 

The detailed procedure using RRC connection release with redirection to IxCS is described in figure B.2.3-1. For 
enhanced IxRTT CS Fall Back procedure, see clause B.2.3a. 
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Figure B.2.3-1 : CS MT call using fallback to CDMA 1x RTT network 

1. UE is E-UTRAN attached and pre-registered with IxRTT CS as defined in clause B.2.1.1. 

2. IxMSC sends a paging request to the IxCS IWS node with Caller Line Identification if available. 

If the call is originated by a priority user or an emergency callback from PS AP, the paging request message from 
the IxRTT MSC to the IWS contains a priority value or an emergency indicator, respectively, as specified in 
3GPP2 specification A.S0008-C v3.0 [39] / A.S0009-C v3.0 [40]. 

3. IxCS IWS node forwards the Ix RTT CS paging request via the SI 02 tunnel to the MME. 

If a priority value or emergency indication was received in the previous step, the SI 02 message also reflects the 
same. 

4. If the UE is in idle state, the MME performs the network initiated Service Request procedure in order to bring 
the UE to active state prior to tunnelling of the Ix RTT CS paging request toward the UE. The paging is 
performed using S-TMSI with CN domain indicator set to "PS". 
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If the SI 02 message contains a priority value or emergency indication, the MME also sets priority indication in 
the SlAP paging request message to the E-UTRAN. The E-UTRAN handles the paging process with priority. 

5. MME forwards the IxRTT CS paging request to the UE. 

6a. Void. 

6b. If the UE accepts CS paging for the CS Fallback to IxRTT, the UE sends an Extended Service Request for 
mobile terminating IxCS fallback to the MME and proceeds with step 7 to step 15 below. 

7. MME sends UE Context Modification Request (CS Fallback Indicator) to indicate the E-UTRAN to move the 
UE to IxRTT. 

If priority value or emergency indication was received in Step 3, the MME also sets priority indication to the E- 
UTRAN in UE Context Modification Request. The E-UTRAN provides preferential treatment to this call in the 
subsequent steps. E-UTRAN responds with UE Context Modification Response. 

8. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

9. E-UTRAN triggers RRC connection release with redirection to IxCS. 

10. E-UTRAN sends an SI UE Context Release Request (Cause) message to the MME. Cause indicates that the SI 
UE Context Release was caused by CS fallback to IxRTT. 

1 1. The MME deactivates GBR bearers towards S-GW and P-GW(s) by initiating MME-initiated Dedicated Bearer 
Deactivation procedure as specified in TS 23.401 [2], and starts the preservation and suspension of non-GBR 
bearers by sending Suspend Notification message to the S-GW. The S-GW releases all eNodeB related 
information (address and TEIDs) for the UE, and sends Suspend Notification message to the P-GW(s). 

12. S-GW and P-GW(s) acknowledges the bearer updates by responding with Suspend Acknowledge. The MME 
stores in the UE context that UE is in suspended status. All the preserved non-GBR bearers are marked as 
suspended status in S-GW and P-GW. The P-GW discards downlink data if the UE is marked as suspended. 

13. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

14. UE tunes to IxRTT and acknowledges the page by transmitting a IxRTT Paging Response message over the Ix 
Access Channel. 

15. Subsequently UE performs the procedure for mobile terminated call establishment as specified in 3GPP2 
A.S0013 [18]. 

Once CS service ends in the IxCS domain the UE returns to E-UTRAN by performing reselection. The EPS service is 
resumed as described in clause 6.5. 

B.2.3a Enhanced CS fallback to IxRTT Procedure 

B.2.3a.1 General 

Enhanced CS fallback to IxRTT procedure may be used when the UE indicates its support of this capability to the 
network. If in addition, the UE also indicates its support of concurrent IxRTT and HRPD PS session handling, this 
indication also allows the network to invoke optimised or non-optimised PS handover procedure concurrently with the 
enhanced CS fallback to IxRTT procedure. 

A network that advertises support for enhanced CS fallback to IxRTT may also advertise support for UEs with dual 
IxRTT and E-UTRAN receiver/transmitter configuration. In such networks, UEs that support enhanced CS fallback to 
IxRTT for dual receiver/transmitter configuration may switch off their IxRTT receiver/transmitter while camped in E- 
UTRAN and register in the IxRTT domain via the SI 02 tunnel. A network advertising these capabilities does not 
suspend the EPS bearers for mobile originated or mobile terminated Ix CS calls for such UEs. Concurrent enhanced CS 
fallback to IxRTT and PS handover to HRPD is not performed for UEs that support enhanced CS fallback to IxRTT for 
dual receiver/transmitter configuration. 

If enhanced CS fallback to IxRTT procedure is not used by the network (i.e., not supported or not configured), the 
network uses RRC connection release with redirection as specified in clauses B.2.2 and B.2.3. 
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NOTE 1. Other 3GPP2 specific procedure (e.g. how UE performs concurrent operation in 3GPP2 network) is 
outside the scope of this specification. 

NOTE 2. E-UTRAN may invoke concurrent optimised active-mode PS handover procedure or non-optimised PS 
handover procedure when it receives Sl-AP: UE Context Modification with CSFB indication, based on 
UE capabiUty and operator configuration. 

B.2.3a.2 Mobile Originating Call without concurrent PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

The following figure describes the mobile originating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent non-optimised PS handover or optimised idle-mode PS handover, or without concurrent PS handover, in the 
normal case. Clause B.2.3b describes the procedure when the procedure is rejected by the MME. 
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Figure B.2.3a.2-1 : Enhanced CS fallback to IxRTT MO Call with no PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

1. UE is E UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1 with enhanced CS fallback 
to IxRTT capability indication to E-UTRAN. The UE may also indicate that it supports concurrent IxRTT and 
HRPD capability. The UE may also be pre-registered with HRPD access using procedures defined in 
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TS 23.402 [27], clause 9.3.1. The UE may also indicate support of enhanced CS Fallback to IxRTT for dual 
receiver/transmitter configuration to E-UTRAN. 

2. UE makes a decision to perform a mobile originated CS call. 

3. UE sends an Extended Service Request for mobile originating IxCS fallback to the MME. 

4. For a UE in active mode, MME sends UE Context Modification Request (CS Fallback Indicator) to E-UTRAN. 
CS Fallback Indicator indicates to the E UTRAN to move the UE to IxRTT. 

E-UTRAN responds with UE Context Modification Response. 

For a UE in idle mode, MME sends Initial UE Context Request (CS Fallback Indicator) to E-UTRAN. CS 
Fallback Indicator indicates to the E-UTRAN to move the UE to IxRTT. E-UTRAN responds with Initial UE 
Context Response. 

If MME determines the CS Fallback procedure needs priority handling based on MPS CS priority in the UE's 
EPS subscription and/or the high priority access indication that the eNodeB includes in the SlAP message in 
step 3, it sets priority indication as well as CS Fallback indicator in the SlAP message to the eNodeB. According 
to operator policy the MME may use CS priority indicator to verify the priority handling of the CS Fallback 
procedure, in the case high priority access indication is received in the Sl-AP message. The E-UTRAN, in 
congestion conditions, provides preferential treatment for this call in the subsequent steps. Also, the E-UTRAN 
shall not trigger enhanced IxCSFB with concurrent optimized PS handover to HRPD access. 

5. E-UTRAN may optionally solicit a IxRTT measurement report from the UE to determine the target IxRTT cell 
to which the CS Fallback will be performed. 

If the network supports PS handover procedure to HRPD then E-UTRAN may optionally solicit an HRPD 
measurement report from the UE to determine whether the target HRPD candidates exist or not. 

6. E-UTRAN sends a HandoverFromE-UTRAPreparation Request message to the UE to start the enhanced IxCS 
fallback procedure. It includes 3Glx Overhead Parameters and RAND value. This message also includes an 
indication that concurrent HRPD handover preparation is not required. 

When both the network and the UE support enhanced CS Fallback to IxRTT for dual receiver/transmitter 
configuration, the E-UTRAN may after Step 4 decide, e.g. due to RF conditions, to direct the UE to turn on its 
second radio to IxRTT and retry the IxCS call directly on the IxRTT access network. For this case, the E- 
UTRAN in the HandoverFromE-UTRAPreparation Request message includes a redirection indicator along with 
optional redirection information. The procedure stops after this step and the UE tunes its Ix radio and retries its 
Ix call in IxRTT while still receiving/transmitting data on E-UTRAN. 

7. The UE initiates signalling for establishment of the CS access leg by sending UL HandoverPreparation Transfer 
message which contains the IxRTT Origination message with called party number. 

8. Messages between MME and IxIWS are tunnelled using the S102 interface. The IxRTT MSC initiates the call 
with the called party number carried in the IxRTT Origination message. 

9. The E-UTRAN performs either Step 9a or Step 9b. Step 9b is only performed when both the E-UTRAN and UE 
support enhanced Ix CS fallback to IxRTT for dual receiver/transmitter configuration. 

9a. The E UTRAN sends Mobility from EUTRA Command to the UE with indication that this is for enhanced Ix 
CS Fallback operation, IxRTT related information, and optionally the HRPD redirection information. The 
IxRTT information contains IxRTT messages related to Ix channel assignment and cause the UE to tune to and 
acquire this Ix channel. This is perceived by the UE as a Handover Command message to IxRTT. 

If the network does not support PS handover procedure to HRPD or if no target HRPD candidates exist then 
E-UTRAN shall release the SI UE context (see step lOa/b) after executing the enhanced CS fallback to 
IxRTT procedure. 

For either concurrent non-optimised PS handover procedure or optimised idle-mode PS handover procedure 
along with enhanced CS fallback to IxRTT, E-UTRAN may also redirect the UE to HRPD as part of this 
procedure. This is indicated by the HRPD redirection information in the Mobility from EUTRA Command. 

If IxRTT CS network cannot support this CSFB request (for example due to resource availability), the DL 
information transfer message is sent instead, with an embedded Ix message that indicates failure to the UE. In 
this case, steps 10, 11, 12 shall be skipped. 
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9b. The E-UTRAN sends DL information transfer message, with the embedded Ix message indicating IxRTT 
preparation success to the UE. Steps 10 and 12 are not performed in this case. 

lOa/b/c. If PS handover procedure is not performed then E-UTRAN sends an SI UE Context Release Request 
(Cause) message to the MME. Cause indicates that the SI UE Context Release was caused by CS fallback to 
IxRTT. The Sl-U bearers are released and the MME starts the preservation and suspension of non-GBR bearers 
and the deactivation of GBR bearers towards S-GW and P-GW(s). The MME sets the UE context to suspended 
status. 

1 1. UE tunes to the IxRTT radio access network and performs Ixchannel acquisition with the IxRTT CS access 
(e.g. IxRTT ESS). A UE supporting enhanced IxCSFB to IxRTT for dual receiver/transmitter configuration 
continues to receive/transmit data on E-UTRAN. 

12. UE and Network follow the appropriate procedure for handling non-optimised PS handover procedure or 

optimised idle-mode PS handover as defined in TS 23.402 [27] if performed. SI UE Context release procedure is 
as specified in TS 23.402 [27] for non-optimised PS handover (clause 8.2.2) or optimised idle-mode PS 
handover (clause 9.4). This step occurs in parallel with step 11. 

B.2.3a.3 Mobile Originating Call with concurrent optimised PS handover 

The following figure describes the mobile originating call procedures for the enhanced CS Fallback procedure to 
IxRTT with concurrent optimised PS handover, in the normal case. Clause B.2.3b describes the procedure when the 
procedure is rejected by the MME. This procedure is not executed for mobile originated priority Ix CS Fallback. This 
procedure is not performed when both the network and the UE support enhanced CS Fallback to IxRTT for dual 
receiver/transmitter configuration. 
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Step 1-5, same as in igure B. 2. 3a. 2-1 
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Figure B.2.3a.3-1 : Enhanced CS fallback to IxRTT MO Call with concurrent optimised PS handover 

1-5. Same as steps 1-5 in figure B.2.3a.2-1. The UE indicates that it supports enhanced CS fallback to IxRTT 
procedure and concurrent IxRTT and HRPD capability. 

6. E-UTRAN sends an Handover From E-UTRA Preparation Request message to the UE to start the enhanced 
IxCS fallback procedure. It includes 3Glx Overhead Parameters and RAND value. This message also includes 
an indication that concurrent HRPD handover preparation is required. 

7. UE starts the enhanced IxCS fallback and optimised PS handover messages (7a, 7b) in a sequential manner. Step 
7a contains the IxRTT Origination message with called party number. 

8a, 9a, 10a, and 8b, 9b, 10b. 

MME treats the enhanced IxCS fallback and HRPD PS handover procedure independently (i.e. MME does not 
link the HRPD message and IxCS fallback message together). 

8a, 9a, 10a is same as shown in step 8 in figure B. 2. 3a. 2-1 

8b, 9b, 10b are messages/procedure for optimised E-UTRAN to HRPD handover procedure as defined in 

TS 23.402 [27], clause 9.3.2. 
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11. The E-UTRAN sends Mobility from EUTRA Command to the UE with indication that this is for enhanced Ix 
CS Fallback operation including the IxRTT message and the HRPD message received over the S102 and SlOl 
tunnels. 

If handover preparation to HRPD is successful but preparation failure message in received from the IxRTT CS 
network via the SI 02 tunnel, the message for IxRTT preparation failure indication is sent to the UE as part of 
the Mobility from EUTRA Command. If handover to HRPD is successful and the eNodeB times out waiting for 
preparation completion message from IxRTT, the E-UTRAN sends a Mobility from EUTRA command with 
only the HPRD message included. In the case that the preparation to HRPD failed but IxRTT is successful, 
E-UTRAN may optionally include HRPD redirection info as part of the Mobility from EUTRA Command. 

In case preparation on IxRTT and HRPD failed with explicit failure messages received on S102 and SOI 
tunnels, the E-UTRAN forwards the received failure messages as DL Information transfers. In this case, steps 12 
and 13 are skipped. 

12. UE retunes to the IxRTT radio access network and performs Ix channel acquisition with the IxRTT CS access 
(e.g. IxRTT BSS), see TS 23.216 [20], clause 6.1.3. 

13. UE and network follow the optimised E-UTRAN to HRPD handover procedure. UE context release procedure 
follows the optimised E-UTRAN to HRPD handover procedure as defined in TS 23.402 [27], clause 9.3.2. This 
step occurs in parallel with step 12. 

B.2.3a.4 Mobile Terminating Call without PS handover, or with concurrent non- 
optimised PS handover or optimised idle-mode PS handover 

The following figure describes the mobile terminating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent non-optimised PS handover or optimised idle-mode PS handover, or without PS handover, in the normal 
case. Clause B.2.3b describes the procedure when the procedure is rejected by the MME. 
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Figure B.2.3a.4-1 : Enhanced CS fallback to IxRTT MT call without PS handover, or with concurrent 
non-optimised PS handover or optimised idle-mode PS handover 

1. UE is E-UTRAN attached and pre-registered with IxRTT CS as defined in clause B.2.1.1 with enhanced CS 
fallback to IxRTT capability indication to E-UTRAN. The UE may also indicate that it supports concurrent 
IxRTT and HRPD capability The UE may also be pre-register with HRPD access using procedures defined in 
TS 23.402 [27], clause 9.3.1. The UE may also indicate support of enhanced CS fallback to IxRTT for dual 
receiver/transmitter configuration to E-UTRAN. 

2-7. Same as step 2-7 in figure B.2.3-1. 



If priority indication in included in the SI AP UE Context Setup or modification message from the MME to the 
E-UTRAN, the E-UTRAN shall not initiate enhanced IxCSFB with concurrent optimized PS handover to HRPD 

access. 

8-17. Same as steps 5-12 of Figure B.2.3a.2-1, with the modifications that the Ix message in step 7 of Figure 
B.2.3a.2-1 provided by the UE to the E-UTRAN is a IxPage Response message and Ix messages in step 9a of 
Figure B. 2. 3. a. 2-1 (step 14a of Figure B.2.3a.4-1) provided by the E-UTRAN to UE may also contain Alert With 
Information message to provide caller line Identification and alerting trigger with Ix channel assignment 

message. 

B.2.3a.5 Mobile Terminating Call with concurrent optimised PS handover 

The following figure describes the mobile terminating call procedures for the enhanced CS Fallback to IxRTT with 
concurrent optimised PS handover, in the normal case. Clause B.2.3b describes the procedure when the procedure is 
rejected by the MME. This procedure is not executed for mobile terminated priority Ix CS Fallback. This procedure is 
not performed when both the network and the UE support enhanced CS Fallback to IxRTT for dual receiver/transmitter 
configuration. 



£75/ 



3GPP TS 23.272 version 11.5.0 Release 11 



81 



ETSI TS 123 272 V1 1.5.0 (2013-06) 



1xCS 

CSFB 

UE 



E- 
UTRAN 



MME 



IxCS 
IWS 



IxRTT 
MSC 



Step 1-8, same as in figure B. 2. 3a. 4-1 



9 HOfromEUTRAPrep. Request 

(3G1x parameter, RAND, con-HRPD HO indication) 



10 



10a. IxCSFB info 
(MEiD, IxPage Response) 



-10b. UL HO Prep (HRPD)- 



11a. ULS1 cclma2000 tunneiing 
(IxCSFB) 



12a. SI 02 Direct Transfer, and IxMSC interworking 



11b. ULS1 cdma2000 tunneiing 
(HRPD) 



12b. S101 
Direct Transfer 

with HRPD 
access node. 



13a. DL SI cdma2000 tunneiing 
(IxCSFB) 



13b. DL SI cdma2000 tunneiing 
(HRPD) 
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Figure B.2.3a.5-1 : Enhanced CS fallback to IxRTT MT Call with concurrent optimised PS handover 

1-8. Same as steps 1-8 in figure B.2.3a.4-1. The UE indicates that it supports enhanced CS fallback to IxRTT 
procedures and concurrent IxRTT and HRPD capability. The UE may also be pre-register with HRPD access 
using procedures defined in TS 23.402 [27], clause 9.3.1. 

9-16. Same as steps 6-13 of Figure B.2.3a.3-1, with the modifications that the Ix message in step 7 of 

Figure B.2.3a.2-1 provided by the UE to the E-UTRAN is a IxPage Response message and Ix messages in 
step 9a of Figure B.2.3.a.2-1 (step 14 of Figure B.2.3a.5-1) provided by the E-UTRAN to UE may also contain 
Alert With Information message to provide caller line Identification and alerting trigger with Ix channel 
assignment message. 

B.2.3a.6 Interaction between enhanced CS Fallback to IxRTT and optimised PS 
handover 

For regular optimized PS handover procedure, it is possible that the UE receives IxRTT CS paging from EPS while 
optimised PS handover to HRPD is in progress. In this case, UE shall ignore the IxRTT CS paging locally. 

B.2.3b Mobile Originated or IVIobile terminated call rejected by the 
IVIIVIE 

The MME may reject an Extended Service Request either for mobile originated or mobile terminated CSFB. In this 
case, the following procedure is executed. 
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Figure B.2.3b-1 : IxCSFB MO or MT call, rejected by MME 

1. UE is E-UTRAN attached and pre-registered with IxRTT CS as defined in clause B.2.1.1. 

2. UE makes a decision to perform a mobile originated CS call or accepts CS paging for the CS Fallback to IxRTT 
(Step 6a, Clause 5.2.3). 

3. UE sends an Extended Service Request for mobile originating/mobile terminating IxCS fallback to the MME. 

4. If the MME decides to reject the Extended Service Request, the MME sends a Service Reject message to the UE. 

Steps 5-10 are executed when Service Reject is sent with a reason code which results in the UE selecting IxRTT 
access, as specified in TS 24.301 [34]. 

5. The UE selects IxRTT access without waiting for RRC Release. 

6. The MME releases SI by sending the SI UE Context Release Command (Cause) message to the eNodeB. Cause 
value indicates that the release is triggered by CS Fallback procedure. 

7. If the RRC connection is not already released, the E-UTRAN sends a RRC Connection Release message to the 
UE. 

8. The E-UTRAN confirms the SI Release by returning an SI UE Context Release Complete message to the MME. 

9-10. Depending on the reason for rejection, MME may start Suspend Notification: 

Suspend Notification: The Sl-U bearers are released and the MME starts the preservation and suspension of 
non-GBR bearers and the deactivation of GBR bearers towards S-GW and P-GW(s). 

S-GW and P-GW(s) acknowledges the bearer updates Suspend Notification and marks the UE as suspended. 
The P-GW discards downlink data if the UE is marked as suspended. 
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B.2.4 Short Message Service (SMS) 
B. 2.4.1 General 

The procedures for SMS in this annex apply only if the UE is IxRTT CS Registered and the CS access domain is 
chosen by the UE and/or the home PLMN for delivering short messages. 

This clause describes both the mobile originating and mobile terminating SMS over SI 02 which uses IxCS procedures 
in EPS. SMS support is based on the S102 reference point between the MME and the IxCS IWS, use of RRC 
Information Transfer message between the UE and the E-UTRAN, and use of SI cdma2000 Tunnelling message 
between the E-UTRAN and the MME. 

B. 2.4.2 Mobile originating SMS 

The following sequence flow shows the delivery of mobile originating SMS sent via the IxMSC while in E-UTRAN. 
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Figure B.2.4.2-1 : Mobile originating SMS sent via the 1xMSC while in E-UTRAN 

1. The IxRTT CS Registration procedure as described in clause B.2.1.1 has been performed earlier. 

2. A mobile originating short message is triggered. If the UE is in idle state, the UE performs the UE triggered 
Service Request procedure, which is defined in TS 23.401 [2]. 
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3. The UE builds the SMS message to be sent as defined in 3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. 
3a. The IxRTT SMS message is transferred from the UE to the E-UTRAN. 

3b. The E-UTRAN forwards the SMS message to the MME. 

4. The MME forwards the SMS message to the IxCS IWS in an S102 Direct Transfer message. 

5. The IxCS IWS acknowledges the message. 

6. The IxCS IWS sends an ADDS Transfer message to the IxMSC containing the SMS message as defined in 
3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. 

7. The IxMSC forwards the SMS message to the Message Centre (MC). If an acknowledgement was requested by 
the UE, the MC responds with an acknowledgement. 

8. The IxMSC forwards the SMS acknowledgement to the IxCS IWS in an ADDS Page message. 

9. The IxCS IWS forwards the SMS acknowledgement to the MME in an S102 Direct Transfer message. 

10. The MME forwards the SMS acknowledgement to the UE. 

11. The MME sends an SI 02 Ack message to the IxCS IWS. This occurs immediately after step 9 if the MSC has 
not requested an acknowledgement from the IxCS IWS. 

12. If the MSC requested an acknowledgement, the IxCS IWS sends an ADDS Page Ack message to the IxMSC. 



B.2.4.3 Mobile terminating SMS 



The following sequence flow shows the delivery of mobile terminating SMS sent via the IxMSC while in E-UTRAN. 
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Figure B.2.4.3-1 : Mobile terminating SMS sent via the IxMSC while in E-UTRAN 
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1. The UE is E-UTRAN attached and registered with IxRTT CS as defined in clause B.2.1.1. 

2. The IxMSC receives the SMS message fi^om the MC and sends an ADDS Page message to the IxCS as defined 
in 3GPP2 A.S0008 [16] and 3GPP2 A.S0009 [17]. The ADDS Page contains the SMS message. 

3. The IxCS IWS sends the SMS message in an S102 Direct Transfer message. 

4. If the UE is in idle state, the MME performs the network initiated Service Request procedure to bring the UE to 
active state prior to tunnelling of the SMS message toward the UE. 

5. The MME forwards the SMS message to the UE. 

6. The MME sends an S102 Ack message to the IxCS IWS. This occurs immediately after step 3 if the MSC has 
not requested an acknowledgement from the IxCS IWS. 

7. If the MSC requested an acknowledgement, the IxCS IWS sends an ADDS Page Ack message to the IxMSC. 

8. After receiving the SMS message at step 5, the UE sends an SMS acknowledgement toward the MC. 

9. The MME forwards the SMS acknowledgement in an S102 Direct Transfer message to the IxCS IWS. 

10. The IxCS IWS sends an SI 02 Ack message to the MME. 

1 1. The IxCS IWS forwards the SMS acknowledgement to the IxMSC. The IxMSC then forwards the SMS 
acknowledgement to the MC. 

NOTE: In addition to above MT SMS procedure (Common Channel SMS), 3GPP2 also defines Traffic Channel 
SMS deUvering method in 3GPP2 A.S0008[16] and A.S0009 [17] that can be used in E-UTRAN-lx 
interworking architecture. In this method, the messages between IxRTT IWS and IxMSC are different 
from those messages specified in this section. There is no additional functional requirement to EPS. 



B.2.5 Emergency Calls 



When UE is performing CS fallback procedure to IxRTT for the purpose of emergency call, it shall indicate to the 
MME that this CS fallback request is for emergency purpose. MME also indicates to the E-UTRAN via the appropriate 
S 1-AP message that this CS fallback procedure is for emergency purpose. 

Emergency call with enhanced IxRTT CS fallback procedure shall be executed without the concurrent PS handover 
procedure. 



B.3 CS Fallback for UEs with dual Rx configuration 
B.3.1 General Considerations 

The following principles are used for supporting CS Fallback for dual receiver UEs: 

The UE with dual Rx configuration attaches separately to each RAT (E-UTRAN, IxRTT) and maintains 
separate registration and mobility procedure handling to each RAT. No coordination is required between the 
E-UTRAN and IxRTT network. 

The UE with dual Rx configuration is able to camp in IxRTT at the same time as it is active or idle in 
E-UTRAN. Camping in IxRTT includes performing IxRTT cell re-selection, reading broadcast channels, 
monitoring paging, performing location updates, etc. according to 3GPP2 specifications. 

The UE with dual Rx configuration is allowed to leave E-UTRAN in order to handle a CS call and/or perform 
registration signalling, and/or sending or receiving SMS in IxRTT. The procedures for leaving E-UTRAN is 
described in clause B.3. 2 and are only allowed if the network indicates that it supports them (this is indicated by 
either the presence of CSFB registration parameters or indication of support for dual Rx CSFB on E-UTRAN 
broadcast channel, TS 36.331 [33]). 

The UE that reports dual Rx configuration to E-UTRAN does not require redirection information. 
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NOTE: Further clarification to the UE behaviour may be needed if the procedure in clause B.3.2, i.e. time 

between transmission of Extended Service Request (3) and reception of RRC Connection Release (5) 
takes too long. 

B.3.2 Procedures for leaving E-UTRAN 

The UE with dual Rx configuration is allowed to leave E-UTRAN in order to handle a CS call and/or perform 
registration signalling, and/or perform location management signalling, and/or sending or receiving SMS in IxRTT. 
When the UE needs to leave E-UTRAN it indicates this to E-UTRAN by using the Extended Service Request procedure 
similar to how MT/MO calls are handed in clauses B.2.2, B.2.2a and B.2.3. The procedure is the same regardless what 
activity is performed in the IxRTT system (e.g. if it is a page response, MO call, re-registration). The procedure is 
shown in Figure B.3.2-1. 



1xCS 

CSFB 

UE 



E- 

UTRAN 



MME 



IxRTT 
MSC 



S-GW/ 
P-GW 



1 . UE is E -UTRAN attached 



I 



2. UE decision 

to perform 
1 xRTT activity 



3. Extended Service Recjuest 



4. UE Context Modifica 



lion Request 
I 

4. UE Context Modification Resoonse 



5. E-UTRAN triggers RRC connection 
releas 



6. S1 UE Context Releasfe 
Request 



9. S1 UE Context Release 



7. Suspend Njtification 



8. Suspend Ac l<nowledoe 



10. IxRTT activity according to 3GPP2 specifications 



Figure B.3.2-1 : Performing IxRTT related activity for dual receiver UEs 

1. UE is E-UTRAN attached the UE may also be registered in IxRTT CS. 

2. UE makes a decision that it needs to perform some IxRTT activity (e.g. in order to respond to an incoming 
IxRTT page, setup a MO call, perform location management signalling, or perform re-registration). 

3. UE sends an Extended Service Request for mobile originating/mobile terminating IxCS fallback to the MME. 
The figure shows the case the UE is in active state in E-UTRAN but the same principles applies if the UE is in 
idle state, TS 23.401 [2]. 

4. MME sends UE Context modification Request (CS Fallback Indicator) to E-UTRAN. CS Fallback Indicator 
indicates to the E-UTRAN to move the UE to IxRTT. 

E-UTRAN responds with UE Context Modification Response. 
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5. The E-UTRAN triggers RRC connection release and continues with step 6. This step may include re-direction 
information if the E-UTRAN indicates support for S102. E-UTRAN that indicates support for dual Rx CSFB 
shall not include any redirection information towards the UE that indicates dual Rx configuration but no support 
for enhanced CS fallback to IxRTT. 

6. E-UTRAN sends an S 1 UE Context Release Request (Cause) message to the MME. Cause indicates that the S 1 
UE Context Release was caused by CS fallback to IxRTT. 

7. The Sl-U bearers are released and the MME starts the preservation and suspension of non-GBR bearers and the 
deactivation of GBR bearers towards S-GW and P-GW(s). by sending Suspend Notification to S-GW and P-GW 
The MME sets the UE context to suspended status. 

8. The S-GW and P-GW(s) acknowledges the bearer updates by responding with Suspend Acknowledge and marks 
the UE as suspended in S-GW and P-GW. When a downlink data arrives at the P-GW, the P-GW should not 
send downlink data if the UE is marked as suspended. 

9. SI UE Context in the E-UTRAN is released as specified in TS 23.401 [2]. 

B.3.3 Procedures for returning to E-UTRAN 

The procedure for returning to E-UTRAN is the same as specified in clause 6.5. 
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Annex C (Normative): 
SMSinMME 

C.1 General 

SMS in MME is an architecture option primarily intended for networks that do not deploy GERAN or UTRAN. SMS in 
MME delivers SMS services over EPS NAS signalling for UE's requiring SMS services. SMS in MME architecture 
option enables support of SMS in the EPS via E-UTRAN without requiring deployment of 3GPP MSCs. 

For SMS in MME the SMS service control is performed by the MME. The MME receives SMS subscriber data and the 
MME verifies whether the subscriber is permitted to obtain SMS services. 

The SMS subscriber data received and used by the MME may be PS subscriber data (the MME directly obtains from 
HSS) or CS subscriber data (the MME obtains via an interworking function as described in clause C.5). 

NOTE: The use of SMS in MME by an operator that also deploys CS service on GERAN or UTRAN may lead to 
increased signalling traffic to the HSS. 



C.2 Architecture 



As outlined in the architecture figure below SMS in MME requires support of SMS functionality in the MME and the 
MME also needs to receive SMS subscription information from the HSS. The SMS subscription information may be 
received through the S6a interface. 
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Figure C.2-1 : SMS in IVIIVIE Architecture 
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Figure C.2-2: SIUIS in IVIIVIE architecture using IWF 

There is no impact on the UE and E-UTRAN. The SMS entities (including SMS router, etc.) functionality to support 
SMS in MME is the same as defined for reference point 2 and 3 in TS 23.040 [14] except the SGd and S6c interfaces 
use Diameter protocols as specified in TS 29.338 [43]. 
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NOTE 1: The HSS may support both a Diameter S6c and a MAP C interface to SMS entities that have not evolved 
to S6c, or the SMS entities may support both interfaces to obtain routing information from HSS's that 
have not evolved to S6c. 

NOTE 2: According to TS 23.040 [14], the SMS-Router is optional and only required for MT SMS. 



C.3 Reference Points 
C.3.1 General 

The following reference points specifically enable support of SMS in MME. 

C.3.2 S6a 

In order to support "SMS in MME" the S6a shall allow the MME to request SMS subscription information and to 
register as a serving node for SMS. If the HSS supports this and has SMS subscription information available, it sends 
SMS subscription data to the MME. The SMS subscription data include for example the barring status of MO-SMS and 
MT-SMS and the MSISDN. If the HSS determines that the MME shall be deregistered for SMS, it shall indicate to the 
MME that it is not registered for SMS. 

C.3.3 S6c 

In order to support "SMS in MME" the Diameter based S6c shall allow the SMS central functions to request routing 
information from the HSS. 

C.3.4 SGd 

In order to support "SMS in MME" the Diameter based SGd shall provide the Short Message Relay Layer (SM-RL) 
between MME serving the UE and SMS central functions. 

C.4 Network Entities 
C.4.1 General 

The following network entities specifically enable support of SMS in MME 

C.4.2 MME 

The MME needs to support the following features: 

- UE-MME NAS procedures for SMS over SGs. 

S6a functionality as described in clause C.3.2. 

SMS procedures between UE and MME including support for the Short Message Control (SMC) and Short 
Message Relay (SM-RL) functions defined in TS 24.01 1 [28]. 

- Reporting UE's availability for receiving MT SMS to the HSS. 
SMS functions including charging and Lawful Interception (LI). 
Support combined EPS/IMSI procedures for "SMS-only" and in these: 

provide a non-broadcasted LAI (not associated with any VLR); and 
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if needed provide a reserved TMSI that cannot cause any ambiguities with other TMSIs (e.g. when the UE 
changes to an area where it needs to derive SMS services from a GERAN/UTRAN MSC); and 

- indicate in the Attach/TAU Accept message that the IMSI attach is for "SMS-only"; and 

notify the HSS it is capable of SMS transfer without the need of establishing an SGs association with an 
MSC; and 

obtain SMS -related subscription information. 

Support the registration procedures for SMS in MME described in clause C.8. 

C.4.3 HSS 

When an MME registers via the S6a including a registration for SMS Request, the HSS registers the MME as an MSC 
for MT SMS (i.e. in response to Send Routing Information (SRI) for SM the MME identity is passed back to the 
SMS-GMSC/SMS router) when the HSS supports and decides to use SMS in MME. This registration as an MSC for 
MT SMS causes the HSS to cancel any old registered MSC. See clause C.8 for the detailed registration procedures. If 
the HSS receives a SRI for other CS Services than SMS it shall treat the UE as if it was detached from the CS domain. 
If the UE subsequently registers with an MSC for CS services, the HSS needs to replace the MME with the new MSC 
as the destination for SMS (but this is not a reason to cancel the MMEs registration for EPS Services). 

NOTE 1: That an HSS that supports SMS in MME registers the MME as an MSC for MT SMS does not affect how 
the information is stored in the HSS, however the HSS reuses the MNRF flag intended for the controlling 
SM delivery via the MSC, for controlling the SM delivery via MME. It only affects what serving node 
identities are returned in response to SRI for SM. In such cases the MME identity is passed back to the 
SMS-GMSC/SMS router where usually the MSC identity is sent. 

NOTE 2: For the PS and SMS only service to work also for outbound roamers, the 3GPP LTE-only operator may 
need to configure CS subscription data for SMS services in its HSS as a visited PLMN may deploy SMS 
over SGs. It may also use an IWF for MAP and Diameter translation. The 3GPP 2G/3G/LTE operator 
may need to upgrade its HSS to ensure that its outbound roamers get SMS services as a VPLMN may 
deploy only SMS in MME. 

An HSS allows an operator to configure a subscription, which is limited to only PS domain services and to SMS service 
via the CS and the PS domain. This limitation is indicated in the PS subscription data as "PS and SMS only". 

NOTE 3: The limitation of a subscription to only PS and SMS services can for example be based on an operator 
agreement with an MTC service provider, that only PS resources shall be used whenever possible. 

When an HSS supports "SMS in MME", i.e. provides all HSS functionahty described for "SMS in MME", and the 
operator configured the HSS to apply that functionality, the HSS indicates "SMS in MME Support" in the data provided 
to an MME. 

NOTE 4: This separate handling of SMS subscriber data in the MME is also for aligning with the deployment 

option of an IWF for S6a that combines PS subscriber data with SMS subscriber data from CS subscriber 
data, where the data part that stems from CS subscriber data may be cancelled in MME independently 
from PS subscriber data. When the PS subscriber data are cancelled then any UE related subscriber data 
are cancelled in the MME. 

If the HSS determines that an MME shall be deregistered for SMS (e.g. because of a removal of SMS subscription, CS 
location update, etc), the HSS shall indicate to the MME that it is not registered for SMS. 



C.5 Roaming considerations 



The SMS in MME architecture is an optional architecture enhancement for operators that wish to avoid to the use of 
MSC and SGs and do not provide Fallback to 3GPP CS services over GERAN or UTRAN. 

To support inbound roamers from networks that do not support the provision of SMS subscription information over S6a 
there are different options to provide interworking, e.g.: 

- SMS over SGs. 
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Use of an interworking function to convert between the S6a with SMS subscription data and S6a without SMS 
subscription data and D for SMS subscription. When the MME sends Ready for SM message to HSS for UE 
reachabiUty notification, the interworking function also needs to convert the Ready for SM message transferred 
via the S6a interface to Ready for SM message transferred via the D interface. 

Operators that do not deploy the SMS in MME architecture option are not required to support the S6a enhancements in 
the HSS or the MME. 



C.6 Unsuccessful Mobile-Terminated SMS Transfer 

The MME or the HSS may not be able to deliver the SM to the UE. This can for example happen when the UE is not 
attached to EPS, when the UE's SMS memory capacity is exceeded, or when the Mobile-terminated SMS is barred. 

When the MME cannot deliver the SM to the UE, the MME shall return a failure report to the SMS GMSC/SMS router. 
The SMS-GMSC/SMS router/HSS procedures for handling the failure report are specified in TS 23.040 [14]. 
Additionally, if the SM failed due to the UE not being reachable, the MME shall set the Mobile-Not-Reachable-Flag-in- 
MME-for-SMS (MNRF-MME) indication in the MME. 

If the UE subsequently becomes reachable and MNRF-MME indication is set, the MME shall send a Ready for SM 
(IMSI, UE-Present) message to the HSS and the MME shall clear the corresponding MNRF-MME indication for that 
UE. 

NOTE: In the case that MME receives an indication from S-GW that the UE has handover to non-3GPP 
coverage, it will not trigger this activity notification. 

If the UE subsequently notifies the MME that SMS memory is available, the MME shall send a Ready for SM (IMSI, 
UE-Memory-Available) message to the HSS. 

Reception of a Ready for SM message or an Update Location Request message by the HSS when MNRF is set, shall 
trigger the SMS alert procedure as defined in TS 23.040 [14]. 



C.7 Information storage 
C.7.1 HSS 

The following table specifies the HSS data defined per UE to support SMS in MME. 

Table C.7.1-1: HSS data 



Field 


Description 


SMS Subscription Parameters 


SMS subscription parameters, e.g. SMS teleservice, SMS barring list. 


Networl< Access Mode (NAM) 


Indicates whether the subscription includes subscriber data allowing for accessing 
PS and or CS domain. 
NOTE 2 


PS and SMS only 


Indicates a subscription which is limited to PS domain services and to SMS service 
via the CS and the PS domain. 
NOTE 2 


MME Registered for SMS 


Indicates that MME has been registered for SMS in the HSS 



NOTE 1: When the UE is not reachable in the MME, the HSS sets the MNRF in the Message Waiting Data 
(MWD) since the MME is registered as an MSC. 

NOTE 2: If "PS and SMS only" is set for this subscriber, NAM is set to "CSh-PS". 

When the HSS functionality for "SMS in the MME" is enabled, the HSS will include an "SMS in MME" feature 
indication along with the UE subscription information to the MME. 
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C.7.2 MME 

The following table specifies the MME data defined per UE to support SMS in MME. 

Table C.7.2-1 : MME Context for SMS 



Field 


Description 


SMS Subscription Data 


SMS subscription parameters, e.g. SMS teleservice, SMS barring list. 


IVIIVIE Registered for SIVIS 


Indicates that MME has been registered for SMS in the HSS 


MNRF-MME 


Indicates whether activity from the UE shall be reported to the HSS. 


Networl< Access Mode (NAM) 


Indicates whether the subscription includes subscriber data allowing for access to 

PS and or CS domain. 

N0TE1 


PS and SMS only 


Indicates a subscription which is limited to PS domain services and to SMS service 

via the CS and the PS domain. 

N0TE1 


SMS in MME Support 


Capability of the HSS to support the SMS in MME feature 



NOTE 1: If "PS and SMS only" is set for this subscriber, NAM is set to "CS+PS". 



C.8 Registration of IVIIVIE for SIVIS 
C.8.1 Request for registration 

An MME supporting SMS in MME that needs to perform a registration with HSS shall follow the following procedure 
to become registered by the HSS also for SMS. 

The following sequence shows the request for registration with the HSS for SMS in MME. 



UE 



MME 



1 . Combined Attach / Combined TA/LA Upc ate Request 



HSS 



2. Location Update 



MSC/VLR 



5. Loc ition Update Answer 



Request 

Q 3. Register for SMS 

4. Cancel Location Request 

, I 

4. Cancel Location Rlesponse 



Figure C.8.1-1 : MME registration for SMS 

1 . The UE initiates combined attach or combined TA/LA Update to an MME. 

2. The MME sends a Location Update Request (SMS in MME feature flag, MME address for MT-SMS routing, 
RegistrationForSMSRequest, "SMS-only" Indication) message to HSS. SMS in MME feature flag indicates that 
the MME is capable of SMS transfer without the need of establishing an SGs association with an MSC. The 
"SMS-only" Indication is included if it has been included in the request from the UE. The MME includes one of 
the following RegistrationForSMSRequest values based on the criteria shown in Table C.8.1-1. 
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Table C.8.1-1 : Registration For SIUIS Request values 



Value 


Description 


SMS in MME Required 


MME does not support SGs; or 

The MME can be configured to use this value when the UE indicates "SMS 
only" or when known that the subscription is "PS and SMS only". 
N0TE1 


SIVIS in IVIIVIE Not Preferred 


The MME can be configured to use this value when the UE indicates "SMS 
only" or when known that the subscription is "PS and SMS only" 
The MME can be configured to use this value when the UE does not indicate 
"SMS only" (i.e. requests CSFB) and the MME has no subscriber data yet 
(when MME is configured to use SGs for "SMS and PS only" subscription). 
NOTE 2 


No Preference for SIVIS in IVIIVIE 


The MME has no preference configured to use SMS in MME or SGs, but both 
options are available from MME perspective. 
NOTE 2 



NOTE 1: If this is set the HSS cannot determine whether the SGs is available. 

NOTE 2: If this value is set it means that the MME supports SGs. UE might or might not indicate "SMS-only". 

3. If the HSS supports SMS in MME and the subscription includes SMS: 

a) if one or more of the following is true: 

- Network Access Mode is PS only; or 

- the MME indicates "SMS in MME Required"; 
then the HSS shall register the MME for SMS; 

b) if the MME indicates "No Preference for SMS in MME" and Network Access Mode is not equal to PS only 
but one or more of the following are true: 

- the UE indicated "SMS-only"; 



the subscription is limited to PS domain services and SMS service via the CS and the PS domain ("PS and 
SMS only"); 

then the HSS should register the MME for SMS; 

NOTE 3: The HSS can decide not to register the MME for SMS since it knows that the MME supports SGs but the 
normal behaviour would be to register for SMS and avoid an SGs association. 

c) if the MME indicates "SMS in MME Not Preferred" and Network Access Mode is not equal to PS only then 
the HSS should not register the MME for SMS; 

NOTE 4: The HSS can decide to register the MME for SMS based on the "PS and SMS only" setting and also on 
other factors including the UE indication for "SMS-Only", it is however assumed the normal behaviour 
would be not to register for SMS. 

d) otherwise the HSS shall not register the MME for SMS. 

If HSS registered the MME for SMS, the HSS stores the MME address for MT SMS. 

4. If the HSS accepts to register the MME identity as an MSC identity for terminating SMS services then the HSS 
cancels the MSC/VLR registration from the HSS. 

5. The HSS sends a Location Update Answer (indication whether the MME has been registered for SMS, 
subscription data including the Network Access Mode and "PS and SMS only" indications, SMS subscription 
data, SMS in MME feature flag) message to MME. 

If the HSS does not register the MME for SMS, it shall indicate that the MME has not been registered for SMS 
and not include any SMS subscription data. 

SMS in MME feature flag indicates that the HSS is capable of supporting the SMS in MME feature. 
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The MME stores the returned data and checks the result of registering the MME for SMS. 
If the registration for SMS was not accepted, the MME does following: 

a. For a PS-only subscription (i.e. the Network Access Mode in the subscription equals "PS-only"), the MME 
shall not establish any SGs association (no SMS services are provided to the UE). 

b. For a "PS and SMS only" subscription where SMS can be provided over CS (i.e. the Network Access Mode 
equals "PSh-CS" and the subscription parameter "PS and SMS only" is set), the MME tries to estabhsh SGs 
for SMS. 

c. For a PS and CS subscription where also other CS services are allowed (i.e. Network Access Mode equals 
"PSh-CS" and the subscription parameter "PS and SMS only" is not set), the MME tries to establish SGs for 
SMS and other CS services. 

C.8.2 Removal of registration of IVIIVIE for SIVIS 

When the HSS needs to indicate to the MME that it is no longer registered for SMS, (e.g. because of a removal of SMS 
subscription, CS location update, etc), the following procedure is applied. 



UE 





MME 




HSS 




MSC/VLR 




















1 . Trigger for Cancellation of SMS in MME 




2. Insert Subscriber 


Data Request 
Data Answer 






3. Insert Subscribe: 















Figure C.8.2-1 : Cancellation of MME registration for SMS 

1 . There is an event that shall trigger the cancellation of the MME being registered for SMS. This may for example 
be the removal of the SMS subscription for the UE, a CS location update, etc. 

2. The HSS sends an Insert Subscriber Data Request (Remove SMS registration) message to the MME to inform 
the MME that it is no more registered for SMS in MME. 

3. The MME sets its "MME Registered for SMS" parameter as not registered for SMS and the "SMS subscription 
data" is considered by the MME as invalid. It acknowledges with an Insert Subscriber Data Answer message to 
the HSS. 

NOTE: A normal Cancel Location of MME which results in the MME no longer being registered for PS services 
for that UE will also render the MME not registered for SMS. 
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